Skip to content

Add support for soft deletes [DATAJPA-307] #676

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

Closed
spring-projects-issues opened this issue Mar 6, 2013 · 12 comments
Closed

Add support for soft deletes [DATAJPA-307] #676

spring-projects-issues opened this issue Mar 6, 2013 · 12 comments
Assignees
Labels
has: votes-jira status: declined A suggestion or change that we don't feel we should currently apply status: pending-design-work Needs design work before any code can be developed type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link

Oliver Drotbohm opened DATAJPA-307 and commented


Issue Links:

  • DATAJPA-1551 Create an API to customize query creation and query processing

  • DATAMONGO-1151 Introduce ability to append queries against a particular collection

  • DATACMNS-293 Add infrastructure for generic query augmentation

Referenced from: pull request #48

74 votes, 64 watchers

@spring-projects-issues
Copy link
Author

Dev Naruka commented

I saw that there is some activity towards implementing soft delete using the query augmentation.

Generally a delete has the following impacts:

  • Delete the entity (DELETE op)
  • Cascade the DELETE op

And soft delete changes the delete action in the following ways:

  • Mark entity as deleted/inactive (UPDATE op)
  • Filter all fetch queries to find active records only
  • Cascade the inactive marking (or soft delete) to other elements

So, the infrastructure is already there to do the first two points. Have anybody planned SOFT-DELETE Cascade yet? or more generically infrastructure level support for providing an opportunity to query augmentors to augment query during a CASCADE.

If not, then I would like to volunteer for the same.

However, I have already started on Querydsl Soft Delete filters and would be doing the native query augmentation also, but it would be great has some foresight on the cascade mechanism

@spring-projects-issues
Copy link
Author

Rob Maskell commented

I'd like to test this and tried adding the following to my build.gradle

ext['spring-data.commons.version'] = '1.11.0.DATACMNS-293-SNAPSHOT'
ext['spring-data.jpa.version'] = '1.9.0.DATAJPA-307-SNAPSHOT'

but it didn't pull in the correct dependencies, I'm using the 1.3 milestone release of spring boot, what did I do wrong?

@spring-projects-issues
Copy link
Author

Jack Matthews commented

Can I just suggest something else that would be great with this feature, that is the ability to query all records in certain situations. In my case I have a requirement to make records active/inactive (which for all intensive purposes inactive=deleted). However, the user has the ability to reactivate (undelete) a records at any time from a management screen. So everywhere in the application the soft delete filter should filter the inactive records out of the queries except on a single administration screen whereby the user can toggle the active flag on the record.

I am thinking an annotation on the spring-data-jpa query might be the way to go.

@IncludeDeleted  <---------------- This annotation could disable the soft delete filtering
@Query('select from account')
private List<Account> findAllIncludingDeleted();

@spring-projects-issues
Copy link
Author

Raúl Gomis commented

Oliver, any update on this feature? are you still planning to introduce it?

@spring-projects-issues
Copy link
Author

alx tr commented

Indeed, what happened with this feature?

@spring-projects-issues
Copy link
Author

swxu2005 commented

Eagerly look forward to this feature, will it come out in Lovelace GA?

@spring-projects-issues
Copy link
Author

nowakprojects commented

Oliver Drotbohm What about this feature? Is there any hope?

@spring-projects-issues
Copy link
Author

SayakMukhopadhyay commented

This issue is being shelved for more than 5 years now. Can we please have a concrete timeline for this? It would help us decide whether to spin our own solution or wait for the official release

@spring-projects-issues
Copy link
Author

Tasos Zervos commented

To add to the last comment.

This is probably one of these low priority (and probably tricky) features.

But I'd like you to make a decision whether you are seriously planning to support it or if not state that you won't. Just that.

People, groups, companies can then make their minds whether they really need this feature (and do something about it, like the last comment suggested) or come up with different ways to achieve the same goals as with soft deletes

@lin-mt
Copy link

lin-mt commented Feb 19, 2021

It's been almost eight years. When will the feature be officially released.

@schauder schauder added the status: waiting-for-triage An issue we've not yet triaged label Feb 19, 2021
@schauder
Copy link
Contributor

schauder commented Mar 1, 2021

Once one starts to look into this in detail it becomes really complex.

You can implement this using native Hibernate features though. Search for "Hibernate soft deletes" in your preferred search engine.

See for reference: spring-projects/spring-data-commons#766 (comment)

We might also consider building an example how this could be achieved in order to explore the limitations. See #2163

@schauder schauder added status: pending-design-work Needs design work before any code can be developed and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 1, 2021
@gregturn
Copy link
Contributor

gregturn commented May 1, 2023

Having also looked at this, I don't think framework should handle it. It's best handled out of band.

@gregturn gregturn closed this as not planned Won't fix, can't repro, duplicate, stale May 1, 2023
@gregturn gregturn added the status: declined A suggestion or change that we don't feel we should currently apply label May 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has: votes-jira status: declined A suggestion or change that we don't feel we should currently apply status: pending-design-work Needs design work before any code can be developed type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

5 participants