-
-
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
belongsTo changes not set isDirty to true #1188
Comments
We could make this work, but keep in mind that I plan to do some refactoring of relationships after beta2 that should get this kind of stuff in shape. |
Could I suggest keeping this issue open, to make sure that it doesn't get resolved in a later beta? It's actually a bit of an issue if, e.g. you're checking |
Any progress on this? This is still an issue and in my opinion it is a bug preventing correct implementation of the use case described by @nragaz. Working with ember 1.2.0 and data beta.3. |
As an imperfect workaround, I've been using this pattern in my models: App.Post = DS.Model.extend({
link: DS.belongsTo('link'),
photo: DS.belongsTo('photo'),
isDirtyWithAssociations: Ember.computed.or('isDirty', 'hasDirtyAssociations'),
dirtyAssociations: (function() {
this.set('hasDirtyAssociations', true);
}).observes('link', 'photo'),
clearDirtyAssociations: (function() {
this.set('hasDirtyAssociations', false);
}).on('didUpdate', 'didCreate')
}); Unfortunately, this will "dirty" the record whenever the relation is set, whether the relation has actually changed or not. So it's not perfect, but it works well enough for my use case. |
@markprzepiora: That is how I've been handling this issue, too. However the observer also fires when the data is loaded the first time, which is annoying. Somehow isLoaded is true and isLoading is false, so I'm not sure how to handle this case. Have you had this issue and if so have you found a solution? |
Just hit this issue myself. Definitely think this is unexpected behaviour. Here's a JSBin that I just created to isolate the issue, and IMHO this isn't how it should work: |
I just hit this issue again, too... have to write an observer against all the BT assocs in my model. (I'm only saving when an object is dirty because I don't want to hit the server for every single object save I do when saivng a tree of objects). FWIW |
I'm with you guys on this. I'm using the isDirty to decide wether to rollback changes when a user cancels. If you change where a relationship points to the model has changed and should be dirty. |
Still a bug in beta.7. Would love to see this fixed. |
dirtiness based on changes to relationships is a pretty complicated issue as far as I can tell. I think there's been a lot of discussions around this in the past year and I'm no longer sure what correct/expected behavior is/should be. I've been out of the loop for a while, so I'm not sure what the current conversation is, but I assume it's related to the conversation around embedded records as well. I'm pretty happy to leave isDirty to be concerned only with changes to |
The issue is complicated. There are many different ways to interpret what "isDirty" could mean. But if you have models like so: var Tag = DS.Model.extend({
name: DS.attr('string'),
person: DS.belongsTo('person')
});
var Person = DS.Model.extend({
name: DS.attr('string'),
tags: DS.hasMany('tag')
}); And you then did something like this: tag.get('person'); //returns null
tag1.set('person', thatGuy); //set person on tag I think most people would expect tag1 to be dirty at that point. I think the complication to this issue comes from whether or not isDirty checks whether the dependent objects are also dirty. IMO, that's unnecessary, but I see the point for debate. |
I agree with @duereg here: I think that we should deliver the expected behaviour, and that |
@markprzepiora have you found a better solution to this yet? Anyone else? My objects are being marked |
I've opened an rfc for this issue here. Please weigh in. |
I have next case:
When I have user model with some
address
, then change thisaddress
to another or null, and checkmodel.get('isDirty')
#=> falseWhy?
The text was updated successfully, but these errors were encountered: