-
Notifications
You must be signed in to change notification settings - Fork 365
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
Indexes and cascade behaviours TBD #88
Comments
+1 for a configurable cascade delete feature |
+1 seems to be mandatory indeed |
+1 |
Current workaround involves a |
|
Hey guys, new loopback user here. I've come to the point where I need a cascading delete feature and in my quest to find it I've stumbled upon this post. I was just curious if anything was ever created to address this?
|
Any progress on this request? this is not just a trivial enhancement, it actually generates bugs when the relation map is not removed in cascade, if you try to use the include filter, it breaks if the relation map still exists.
|
+1 I really need an option to enable Cascading Deletes |
+1 |
3 similar comments
+1 |
+1 |
👍 |
@ritch and @raymondfeng - it sounds like it has been almost ready for a long time, where does it stand in the pipeline? https://waffle.io/strongloop/loopback |
+1 |
I've written a mixin that pretty much covers the use cases described here. In particular, in MyModel.js if you write
If unlink is If unlink is If there's interest, I can submit a pull request -- my only question is: to which project? the built-in mixins seem to live in the |
+1 |
+1, any word on the status of this? |
+1, Im in serious need of such a feature. Any status updates? |
@CjS77 would you have a gist handy for the mixin you've written by chance? |
Wroks for me. YMMV :) |
@CjS77 Cheers for that! |
I found that @CjS77 's solution worked only for a single relation. As soon as there were multiple relations to cascade it would only delete the first relation as the first resolved delete would call next(); I've made a slight change which waits for all deletes to resolve before calling next: |
+1 !!! |
+1 What's the status of this issue? I really hope that a solid cascade-support will be implemented soon as I find it quite valuable for more complex systems. |
+1 |
+1 No changes on the status? |
@raymondfeng it seems like foreign key indexes are still not being created, did that ever get merged in? Thanks! |
Just in case if people still want this, The code below walks through the tree of relations and destroys them, use at your own risk.
` |
I have created npm package |
This needs to happen on the connector / SQL definition layer, so if a row is deleted manually or via an external admin tool then it cascades @superkhau Without the cascade client code will easily break when it expects included properties that don't come through. |
A Co-worker of mine pointed out that each Loopback foreignKey element has an Using those, we can add No where in Loopback documentation is this mentioned, so if we can have that added, that'd be nice. tl;dr: *quick edit |
As discussed in https://groups.google.com/forum/#!topic/loopbackjs/z7bW9UFJzCU
I recently noticed some issues or sub-optimal behaviour with loopback models storage in the database :
Example : when i remove items in table Product and/or Category, via loopback API, items in
product
andcategory
collection are deleted, but notproductcategory
collectionIn a RDBMS, I suspect the best practice is to define FK and cascade behaviour in the DB engine, but in noSQL like mongodb, should not this be taken care of by Loopback ?
The text was updated successfully, but these errors were encountered: