Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] bug in AuditListTableMappingWithRanges?
[CDO] bug in AuditListTableMappingWithRanges? [message #940030] Thu, 11 October 2012 08:49 Go to next message
Martin Blühweis is currently offline Martin BlühweisFriend
Messages: 11
Registered: February 2012
Location: Innsbruck, Austria
Junior Member
hi all,

i think there's a bug in this method:

public void visit(CDORemoveFeatureDelta delta)
{
  finishPendingRemove();
  this.lastRemovedIndex = delta.getIndex();
  if (AuditListTableMappingWithRanges.TRACER.isEnabled())
  {
    AuditListTableMappingWithRanges.TRACER.format("Delta Removing at: {0}", new Object[] { Integer.valueOf(this.lastRemovedIndex) });
  }
  AuditListTableMappingWithRanges.this.removeEntry(this.accessor, this.id, this.oldVersion, this.newVersion, this.lastRemovedIndex);
}


it works just for deleting the last list element.

consider following situation:
* i have a list with 5 elements (indices 0-4)
* now i want to remove the element on index 2
* finishPendingRemove() calls moveOneUp(...) for the indices 3 and 4
* moveOneUp(...) executes sql statements for every element: delete it at index n, insert it again at index (n-1)
* so the element at index 3 will be deleted - adding it at index 2 fails (SQLException -> Index violation), because the element at index 2 (which i want to delete) still exists

so i guess it can be fixed easily by calling removeEntry(...) before finishPendingRemove().

my questions:
* am i right or do i misunderstand the code?
* is there a workaround? some important features in my application do not work now Sad

thanks in advance,
martin
Re: [CDO] bug in AuditListTableMappingWithRanges? [message #940142 is a reply to message #940030] Thu, 11 October 2012 10:58 Go to previous messageGo to next message
András Péteri is currently offline András PéteriFriend
Messages: 22
Registered: January 2010
Junior Member
Hello Martin,

The intended order of operations is the following:

- The first visit(CDORemoveFeatureDelta) should not do anything inside finishPendingRemove() if no removal took place earlier (lastRemovedIndex == -1). It should save the removed index to lastRemovedIndex in the next line, then only remove the element in question at the end, temporarily leaving an empty spot in the list;

- Following visit(...) methods check if there is a deletion in progress by calling finishPendingRemove() at the beginning of each method. If this is the case, moveOneUp(...) is called with the saved index, completing the deletion. Splitting removals this way enables CDO to leave moveOneUp(...) operations out in case the removed element's place is taken immediately by the last element of the list, useful for unordered lists;

- After finishing the iteration over CDOFeatureDeltas, finishPendingRemove() is called again for completing a possible last pending removal.

Did you have additional CDORemoveFeatureDeltas in the example list delta, or just a single remove? Is the list modeled as unordered?
Re: [CDO] bug in AuditListTableMappingWithRanges? [message #940178 is a reply to message #940030] Thu, 11 October 2012 11:43 Go to previous messageGo to next message
Martin Blühweis is currently offline Martin BlühweisFriend
Messages: 11
Registered: February 2012
Location: Innsbruck, Austria
Junior Member
Hi Andras,

thx for the quick reply.


Andras Peteri wrote on Thu, 11 October 2012 12:58
Hello Martin,

The intended order of operations is the following:

- The first visit(CDORemoveFeatureDelta) should not do anything inside finishPendingRemove() if no removal took place earlier (lastRemovedIndex == -1). It should save the removed index to lastRemovedIndex in the next line, then only remove the element in question at the end, temporarily leaving an empty spot in the list;

- Following visit(...) methods check if there is a deletion in progress by calling finishPendingRemove() at the beginning of each method. If this is the case, moveOneUp(...) is called with the saved index, completing the deletion. Splitting removals this way enables CDO to leave moveOneUp(...) operations out in case the removed element's place is taken immediately by the last element of the list, useful for unordered lists;

- After finishing the iteration over CDOFeatureDeltas, finishPendingRemove() is called again for completing a possible last pending removal.

sounds correct for me Smile

Andras Peteri wrote on Thu, 11 October 2012 12:58
Did you have additional CDORemoveFeatureDeltas in the example list delta, or just a single remove? Is the list modeled as unordered?

it's a single remove an my list is unordered.


could you take a look at the stacktrace, please? (the exception message means a duplicate key violation)
org.eclipse.emf.cdo.util.CommitException: Rollback in DBStore: org.eclipse.net4j.db.DBException: java.sql.SQLException: Eine Zeile mit doppeltem Schlüssel kann in das 'dbo.Employee_examinations_list'-Objekt mit dem eindeutigen 'Employee_examinations_list_idx0'-Index nicht eingefügt werden.
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AuditListTableMappingWithRanges.addEntry(AuditListTableMappingWithRanges.java:914)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AuditListTableMappingWithRanges.access$3(AuditListTableMappingWithRanges.java:888)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AuditListTableMappingWithRanges$ListDeltaVisitor.moveOneUp(AuditListTableMappingWithRanges.java:785)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AuditListTableMappingWithRanges$ListDeltaVisitor.finishPendingRemove(AuditListTableMappingWithRanges.java:738)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AuditListTableMappingWithRanges.processDelta(AuditListTableMappingWithRanges.java:561)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalAuditClassMapping$FeatureDeltaWriter.visit(HorizontalAuditClassMapping.java:729)
	at org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.accept(CDOListFeatureDeltaImpl.java:422)
	at org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.accept(CDORevisionDeltaImpl.java:303)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalAuditClassMapping$FeatureDeltaWriter.process(HorizontalAuditClassMapping.java:692)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalAuditClassMapping.writeRevisionDelta(HorizontalAuditClassMapping.java:605)
	at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.writeRevisionDelta(DBStoreAccessor.java:552)
	at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.writeRevisionDeltas(DBStoreAccessor.java:537)
	at org.eclipse.emf.cdo.spi.server.StoreAccessor.doWrite(StoreAccessor.java:101)
	at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.write(StoreAccessorBase.java:149)
	at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:487)
	at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:43)
	at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
	at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:262)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:96)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
	at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
	at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
	at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
	at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
	at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)



hope it helps - otherwise i'll debug inside in the afternoon to see & understand what's going on there Wink
Re: [CDO] bug in AuditListTableMappingWithRanges? [message #940187 is a reply to message #940178] Thu, 11 October 2012 11:54 Go to previous messageGo to next message
András Péteri is currently offline András PéteriFriend
Messages: 22
Registered: January 2010
Junior Member
This one is probably in connection with https://bugs.eclipse.org/bugs/show_bug.cgi?id=390283 then. Can you check if the attached patch for that bug fixes the problem?
Re: [CDO] bug in AuditListTableMappingWithRanges? [message #940273 is a reply to message #940187] Thu, 11 October 2012 13:35 Go to previous message
Martin Blühweis is currently offline Martin BlühweisFriend
Messages: 11
Registered: February 2012
Location: Innsbruck, Austria
Junior Member
Andras Peteri wrote on Thu, 11 October 2012 13:54
This one is probably in connection with https://bugs.eclipse.org/bugs/show_bug.cgi?id=390283 then. Can you check if the attached patch for that bug fixes the problem?

yes, it looks like.

setting the ordered flag to true (no matter, my lists contain <100 entries) fixes the problem for me.

i hope i can spend some time to test your patch too.

thanks a lot for your help Smile

Previous Topic:EMF Metrics Tooling
Next Topic:[XCore] ChildCreationExtenders and ExtensibleProviderFactory issue
Goto Forum:
  


Current Time: Fri Apr 26 03:50:35 GMT 2024

Powered by FUDForum. Page generated in 0.03128 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top