-
Notifications
You must be signed in to change notification settings - Fork 40
Removing objects from datastore #28
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
base: master
Are you sure you want to change the base?
Conversation
…er models that reference it. This property is used during delete to assist with the complete removal of this object from the store.
Thanks a lot for this, looks solid to me. Will review it ASAP. Cheers, On Thursday, 10 March 2016, David Skinner notifications@github.com wrote:
Lucas Hosseini |
} | ||
}); | ||
} else if (self.graph[assoc.type][assoc.id][assoc.relation].id === model.id) { | ||
self.graph[assoc.type][assoc.id][assoc.relation] = new JsonApiDataStoreModel(self.graph[assoc.type][assoc.id][assoc.relation]._type); |
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.
Why not make it null
here?
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 certainly could be null. I think I originally had it as null, but due to how we are using the data store, we found it useful to have the blank model there. I guess it could go either way. For a more global approach do you think null would be best?
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 would be more consistent with what we do there.
Awesome, this feature is clearly a must! A few minor remarks, but I'd love to merge that ASAP. |
I've pushed up the changes as per our conversation thus far. On the property name issue, I think _dependents is fairly descriptive. Though if someone has a better idea for a name I'd be happy to change it. |
model[key] = findOrInit(rel.data); | ||
var ref = findOrInit(rel.data); | ||
ref._dependents.push({id: model.id, type: model._type, relation: key}); | ||
model[key] = ref; |
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.
Nitpicking: how about
model[key] = findOrInit(rel.data);
model[key]._dependents.push(...);
instead?
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.
Done! :)
Great, thanks! |
The original work I had done on this is on another computer with my testing environment set up. I don't have a testing setup on this machine. If I have some time next time I am by it, I'll try and write some. Though might be a few days... :\ |
No worries, I can do it. Note that running the tests should just be a matter of
|
…ing a relationship to only add to the _dependents array IF the model hasn't been referenced before. Delete will also remove the pointer in the _dependents array when the model is deleted.
Thanks for the reminder! I had some extra time and setup the tests on this machine. I went and added a test and discovered a few tweaks that would help keep it clean. Let me know if there are any adjustments needed. :) |
@@ -1,6 +1,6 @@ | |||
|
|||
|
|||
<!-- Start src/jsonapi-datastore.js --> | |||
<!-- Start src\jsonapi-datastore.js --> |
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.
Any reason for this change?
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.
Guess my machine automatically changed that when I ran gulp. I made sure it got reverted.
Nice, I think we're really close now, a tiny bit of cleanup and we should be good to merge! |
Added the _addDependence and _removeDependence. |
Awesome, will review ASAP! |
found; | ||
|
||
found = self._dependents.filter(function(dependent) { | ||
return dependent.id === id && dependent.type === type; |
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 we should check for relationship key equality as well, as a model may have several back-references from a same model on different relationships (think post has_one author, and post has_many commenters).
*/ | ||
removeRelationship(type, id, relName) { | ||
var self = this; | ||
self._removeDependence(type, 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.
By doing this we are effectively removing all dependences to the model, although we should probably just remove the dependence for the current relationship (which implies that _removeDependence
would have to take a key
parameter as well).
var self = this, | ||
found; | ||
|
||
self._dependents.forEach(function(val, idx) { |
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 we could use find
since we want to guarantee that those records are unique (provided we add a key
parameter to the _removeDependence
method). It would be slightly longer, but I believe would make the purpose of the code clearer.
Hey @skinnerdev – any news on this front? |
I saw issue #26 and realized we had this logic on a fork of this project. Here is the code we've implemented to provide this functionality.
I've added a property to data store models that holds information about other models that reference it. This property is used during delete to assist with the complete removal of this object from the store. Any time a model with references is added to the store, we touch the references and "inform" them that they have been referenced.
The delete process uses the data in the associations array to find other objects in the store that reference the model to be deleted. If the deleted model is referenced with a hasMany relationship, the model to be deleted is removed from the referencing model's relationship array. If the reference is a hasOne/belongsTo relationship, the referencing model's relationship is given a new blank datastore model with only the _type property set.