Returning option for Model.destroy
See original GitHub issueModel.update(...)
already accepts returning = true
option - any plans to add same option for Model.destroy(...)
- would be very nice feature.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:1
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Sequelize how to return destroyed row - node.js - Stack Overflow
Here we are returning a promise as Model.destroy which will resolve to result object received from the call to Model.find .
Read more >Using `Returning` with Sequelize and Postgres | by Zach C
Sequelize uses an option called returning to specify which data returns from a commands like .destroy() or update() . Let's look at three...
Read more >sequelize.Model.destroy JavaScript and Node.js code examples
Delete multiple instances, or set their deletedAt timestamp to the current time if `paranoid` is enabled.
Read more >Final Class: Model - Oracle
destroy (options) : {boolean} ... Delete the record represented by this model object from the data service. If the server responds with virtual ......
Read more >Active Record Callbacks - Ruby on Rails Guides
before_destroy callbacks should be placed before dependent: :destroy associations (or use the prepend: true option), to ensure they execute before the records ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Well, it would be a very nice feature. I’m using the .destroy method and I would use the “returning” option as well. As update has this already, it would make sense to pull this into a next step. About backward compatibility, if now return only “rows”, into the first parameters, it wouldn’t be the same as update to return the deleted instance in the second parameter ? I mean, I’m new to the library at all, but it didn’t make sense for me not putting it into the second parameter as it does not exist second parameter at all
It may return whole rows (deleted ones) or specified columns:
So it “behaves” same as
RETURNING
inUPDATE
This is very handy if you want to delete something and then for example send email based on deleted data - instead of fetching row and then deleting it you can just delete and fetch in one query (one server-database roundtrip less).