You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Warwick Burrows <wa...@e2open.com> on 2004/11/05 01:03:02 UTC

Defect in retrieveRevisionDescriptors

Hi,

I have found a defect (bugzilla 32072) in the StandardRDBMSAdapter module
and want to go over the fix before I submit it for inclusion in the source
tree. The problem I have seen is that after forking a revision that the
first time that you checkin a revision on the new branch that DB2 will fail
the insert into the VERSION_PREDS table because it finds two identical
"successor" entries for a single revision in the revision descriptors object
and the exact same entry pair can't be inserted twice into the table as each
entry must be unique. The problem seems to be due to this SELECT statement
in retrieveRevisionDescriptors in the StandardRDBMSAdapter:

	select pvh.REVISION_NO from VERSION_HISTORY vh, VERSION_HISTORY pvh,
VERSION_PREDS vp, URI u where pvh.VERSION_ID = vp.VERSION_ID and
vp.VERSION_ID = vh.VERSION_ID and vh.URI_ID = u.URI_ID and u.URI_STRING = ?
and vh.REVISION_NO = ?

In the case that leads to the problem above this SELECT returns two rows if
the version we're looking for has been forked. Eg. if the version is 1.1 and
we have forked to a 1.1.1 branch then the VERSION_PREDS table now has two
entries in it for the "1.1" version. It seems logical that there can be more
than one entry for each version id in the VERSION_PREDS table as the unique
key for the table is the version_id and predecessor_id pair indicating that
the version_id isn't unique. So the problem seems to be that the above
select statement should cater for the fact that two entries could be in the
VERSION_PREDS table and that the SELECT against it can return multiple
identical entries. So what I have done to fix this is change the SELECT to
be:

	select DISTINCT pvh.REVISION_NO from VERSION_HISTORY vh, (etc)

Which will eliminate duplicates and return the correct data. The DISTINCT
keyword is a standard SQL keyword so it should work for all DB
implementations under the standard adapter. Let me know if you see a problem
otherwise I will submit it as a fix.

Thanks,
Warwick


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org