-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] [Feat] implements Schema to separate store logic and model description from the model layer. #4584
Conversation
2396e4e
to
1549c26
Compare
var id = coerceId(inputId); | ||
var internalModel = this.typeMapFor(typeClass).idToRecord[id]; | ||
let id = coerceId(inputId); | ||
let internalModel = this.schemaFor(modelName).recordMap.idToRecord[id]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few lines bellow you saying recordMap.idToRecord[id]
holds records
var record = idToRecord[id]; | ||
let id = coerceId(inputId); | ||
let schema = this.schemaFor(modelName); | ||
let record = schema.recordMap.idToRecord[id]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few lines up you saying recordMap.idToRecord[id]
holds internalModels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be internalModel, I was carrying over the old names and should have noticed the old one was bad
idToRecord: new EmptyObject(), | ||
records: [], | ||
metadata: new EmptyObject(), | ||
type: this.model |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this.model
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's nothing, it should be this.modelClass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you keeping type
here and bellow because it would be too much work for now to refactor everything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tchak more or less yes, I actually went down the road of refactoring everything in an earlier spike, but the problem is that a few of these places leak to public code and I'm no sure if we consider this one to yet or not.
|
||
referenceFor(type, name) { | ||
referenceFor(modelClass, name) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here type
is referring to relationship kind
: hasMany
or belongsTo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops, will change that back. I think maybe we should consistently refer to this as kind
internally? I noticed this confusion in another spot too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for using kind
instead of type
Early results for this branch have it at roughly (4ms / 238 records of 1 type over the 28ms of the internal-model branch it branches off of (this branch does not include the cache upgrades currently). This is a happy surprise, because most of the perf improvements this unlocks have not been worked on yet. |
will give a second review tomorrow, but i am crying tears of joy right now. |
|
||
get type() { | ||
deprecate(`InternalModel.type has been deprecated in favor of InternalModel.modelClass`, { | ||
id: 'ember-data.private.type-to-modelClass' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs an until: "3.0"
|
||
referenceFor(type, name) { | ||
referenceFor(modelClass, name) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for using kind
instead of type
} | ||
if (!this._serializer) { | ||
throw new Error('Cant find serializer!'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a leftover from refactoring? Do we need this check for an serializer, since there should always be a default serializer, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it's just a left over check for something that was failing for me early in the process and can be removed
inverse = inverseSchema.relationships[inverseName]; | ||
|
||
assert("We found no inverse relationships by the name of '" + inverseName + "' on the '" + inverseSchema.modelName + | ||
"' model. This is most likely due to a missing attribute on your model definition.", !Ember.isNone(inverse)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/attribute/relationship/
|
||
if (this._schemas === null) { | ||
this._schemas = new EmptyObject(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to initialize this._schemas
in the init
.
*/ | ||
typeMapFor(typeClass) { | ||
typeMapFor(modelClass) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be renamed to recordMapFor
to better reflect what is returned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pangratz yes, but I suspect we leaked this publicly and should add a deprecation.
1549c26
to
52ebb7f
Compare
52ebb7f
to
bfa9184
Compare
I rebased this, but I I want to shrink it's scope a bit and reconsider things. I should be able to land this by end of day tomorrow by branching off of #4664 and moving parts of the schema into I think this implementation at this point in time is too broad, because we will likely want to expose a primitive (not necessarily exactly this one) to adapters in place of modelClass, but this one is not ready for that. I have a plan, but it's happily more incremental, and will turn into multiple simpler PRs instead of one larger one. |
As luck would have it, once I started trying to port some of the iterator / model parse optimizations into DS.Model, turns out we still need this! So nvm on the new direction, cleaning up this PR and shifting it's focus a wee bit to be an object tied more closely to DS.Model for now. |
chore(modelClass): converts InternalModel.type to InternalModel.modelClass houston, we have a schema move typeMap into schema port typeMapFor usage to schemaFor().recordMap type/typeClass => modelClass, type => modelName
bfa9184
to
f22850a
Compare
Closing in favor of #4865 |
TODO