Skip to content

Versioning Updates (Part 2 of Multiple Catalogs) - #2034

Merged
jmataya merged 14 commits into
masterfrom
feature/version-in-phoenix
Jun 16, 2017
Merged

Versioning Updates (Part 2 of Multiple Catalogs)#2034
jmataya merged 14 commits into
masterfrom
feature/version-in-phoenix

Conversation

@jmataya

Copy link
Copy Markdown
Contributor

Part 1:#1976

Summary

This PR starts the rebuild of Object Framework inside of Phoenix. This is a necessary component of the Multiple Catalogs work because it allows for truly context-aware and fully versioned products, which is the basis for how catalogs work. At the moment, these changes are not used and live side-by-side with the existing object model.

This PR contains the following changes:

  • A new set of models in objectframework for form/shadow/commit/etc. The word Object has been removed from all of them, as it was just superfuluous and confusing
  • Simpler and more easily tested utilities for working with forms and shadows
  • Unifies all heads under a single table so that they can be modified by a standard service
  • Renames ObjectContext to View
  • Creates a single base illuminated object: Content. This means that no product/sku/catalog/etc. service should know about the implementation details of form and shadow.
  • Object Link is removed and replaced with a map called relations (maps a shadow to commits of related objects)

Roadmap

  • Add update and archive services
  • Create a new products service
  • Implement product models in the new service
  • Deprecate old services

@mempko

Copy link
Copy Markdown
Contributor

OMG very exciting! Is this model compatible with gizmo?

@jmataya

Copy link
Copy Markdown
ContributorAuthor

@mempko yup! It's the same data model as Gizmo


case object ObjectNotFoundAtCommit {
def apply(tableName: String, commitId: Int): NotFoundFailure404 =
NotFoundFailure404(s"$tableName with commit $commitId not found")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this must be a client-facing error msg?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see the argument of using the term "version", but this will be a client-facing action (requesting something at a specific version/commit) and it's definitely an improvement over our current error messages that show form/shadow/etc in the logs.

* that are implemented on top of this model should leverage Content.
*/
case class Content(id: Int,
kind: String,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might need an ADT instead of pure String

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this level, I'd rather it not be an ADT. Object Framework doesn't know what kind of content is being created, as that's solely up to the implementer. My gut is to keep it as a string.


object ContentAttribute {
def build(shadowAttribute: JValue, form: Form): Either[Failures, ContentAttribute] = {
def attributeType = shadowAttribute \ "type"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be val

filter(_.attributes +>> key === value)

def filterByLanguage(lang: String): QuerySeq =
filterByAttribute("lang", lang)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extract "lang" as a constant on some object


val returningLens: Lens[View, Int] = lens[View].id

def filterByName(name: String): QuerySeq =

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say findByName or even byName can be sufficient method name

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only kept this name as verbose as it is because we seemed to have prefixed filter when returning a QuerySeq. If we want to change that, I'm totally cool with shortening.

import core.failures.{Failure, NotFoundFailure404}

case object CorruptedContentObject extends Failure {
override def description = "Unable to parse corrupted content object"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This screams for additional logging

}

private def validateRelations(relations: Content.ContentRelations)(
implicit ec: EC): Seq[DbResultT[Unit]] =

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if DbResultT#sequence could be useful here to "invert" return type

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could. Right now that's happening through Starfish here:

https://github.com/FoxComm/highlander/pull/2034/files/84cb481ec4d50234874f80fef0159e9704cb9c8e#diff-ef66a172e781ef807dc1ff0cc6639717R47

You think it's worth doing that explicitly in this method?

// migration logic that lives in the main integration tests. At some point,
// moving it back to that project will make sense once we have a better idea
// of how modules will do things like manage the database.
// -- Jeff

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of moving testframework as shared dependency — will pick this up when I do. Thanks for the comment

}
}

trait Fixture {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, so I was thinking of moving away from this new Trait pattern. Here on trait you have 2 vals, so an object would be perfect here. As for SkuFixture, create a class (or case class) and instantiate it when you need some fixture data. What do you think?

@narmanarma left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

V4.121 and V4.121 sql versions already exists at master, please rename this to new values, timestamp one would be great.

@jmataya
jmatayaforce-pushed the feature/version-in-phoenix branch from 93e47ab to 1a5dba3CompareJune 16, 2017 02:52
@jmataya
jmataya merged commit fd8522e into masterJun 16, 2017
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@jmataya@mempko@narma@annappropriate