Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312670

Summary:	[DB] Delete objects completely from the database in non-branching mode
Product:	[Modeling] EMF	Reporter:	Kai Schlamp <schlamp>
Component:	cdo.core	Assignee:	Stefan Winkler <stefan>
Status:	CLOSED DUPLICATE	QA Contact:	Eike Stepper <stepper>
Severity:	enhancement
Priority:	P3	CC:	sobeos, stefan, stepper, techteam
Version:	4.2
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Kai Schlamp

2010-05-12 13:11:21 EDT

Build Identifier: I20100312-1448

When I remove objects from a list that is backed up by CDO, the object are not really deleted in the database. It is just not visible anymore when accessing the list and in the database "version" is changed to "-2". I don't need the versioning stuff. I need the objects completely removed from the database. This was done by default in an older release. How do I enable it again (resp. disable the versioning? I already set Props.SUPPORTING_AUDITS and Props.SUPPORTING_BRANCHES to "false". I also created my mapping by using CDODBUtil.createHorizontalMappingStrategy(false).

Reproducible: Always

Comment 1 Stefan Winkler

2010-05-14 05:19:22 EDT

Mhh ... Eike, would it be harmful (regarding functionality, not performance) to remove the "ghost" revisions from the non-audit code?


Eike gave in an email a reason for the existence of negative version numbers: 
to explicitly state that a revision is not in existance any more and therefore to also reflect this is the revision caches so that accessing a non-existing revision does not cause a server roundtrip.

The question here is: can't we (in the long term) simulate this behaviour at least in some cases (non-audit, e.g.) without the persistent deletion marks? Can't we introduce a logic that would create the "ghost" revision on the fly if needed.


Eike, what do you think?

Comment 2 Eike Stepper

2010-05-18 06:53:24 EDT

I suggest that we make this behaviour configurable and just try it. Who wants to work on this?

Comment 3 Eike Stepper

2010-06-29 04:51:19 EDT

Rebasing all outstanding enhancements requests to version 4.0

Comment 4 Eike Stepper

2011-06-23 03:59:11 EDT

Moving all open enhancement requests to 4.1

Comment 5 Joe Sobeos

2012-08-07 08:10:47 EDT

Status: New; Version: 4.1;
-> I thought version 4.1 is already released?
So, when will we get the problem fixed?

Comment 6 Eike Stepper

2012-08-07 11:12:47 EDT

I've just not managed, yet, to update the version fields of the unresolved bugs ;-(

This one is on my priority list but I can not estimate when I will finally arrive here. Maybe you would like to help us and provide a patch?

Comment 7 Eike Stepper

2012-08-14 22:57:54 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 8 Eike Stepper

2012-11-12 04:54:07 EST

Resolved via bug 351068.

*** This bug has been marked as a duplicate of bug 351068 ***