Skip to content
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

Removing objects from datastore #28

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

skinnerdev
Copy link

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.

…er models that reference it. This property is used during delete to assist with the complete removal of this object from the store.
@beauby
Copy link
Owner

beauby commented Mar 10, 2016

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:

I saw issue #26 #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.

You can view, comment on, or merge this pull request online at:

#28
Commit Summary

  • Added a property to datastore 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.

File Changes

Patch Links:


Reply to this email directly or view it on GitHub
#28.

Lucas Hosseini
lucas.hosseini@gmail.com

}
});
} 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);
Copy link
Owner

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?

Copy link
Author

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?

Copy link
Owner

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.

@beauby
Copy link
Owner

beauby commented Mar 11, 2016

Awesome, this feature is clearly a must! A few minor remarks, but I'd love to merge that ASAP.

@skinnerdev
Copy link
Author

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;
Copy link
Owner

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?

Copy link
Author

Choose a reason for hiding this comment

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

Done! :)

@beauby
Copy link
Owner

beauby commented Mar 11, 2016

Great, thanks! _dependents seems good to me. Last thing needed would be one or two tests. I could probably write some tomorrow if you don't have time.

@skinnerdev
Copy link
Author

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... :\

@beauby
Copy link
Owner

beauby commented Mar 11, 2016

No worries, I can do it. Note that running the tests should just be a matter of

$ npm install
$ gulp test

…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.
@skinnerdev
Copy link
Author

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 -->
Copy link
Owner

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?

Copy link
Author

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.

@beauby
Copy link
Owner

beauby commented Mar 11, 2016

Nice, I think we're really close now, a tiny bit of cleanup and we should be good to merge!

@skinnerdev
Copy link
Author

Added the _addDependence and _removeDependence.

@beauby
Copy link
Owner

beauby commented Mar 11, 2016

Awesome, will review ASAP!

found;

found = self._dependents.filter(function(dependent) {
return dependent.id === id && dependent.type === type;
Copy link
Owner

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);
Copy link
Owner

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) {
Copy link
Owner

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.

@beauby beauby mentioned this pull request Mar 15, 2016
@beauby
Copy link
Owner

beauby commented Oct 21, 2016

Hey @skinnerdev – any news on this front?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants