Bug 37254 - RDBMS store and Branching.
Summary: RDBMS store and Branching.
Status: NEW
Alias: None
Product: Slide
Classification: Unclassified
Component: Stores (show other bugs)
Version: 2.1
Hardware: All All
: P1 major (vote)
Target Milestone: ---
Assignee: Slide Developer List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-26 14:06 UTC by Honor
Modified: 2005-11-21 16:28 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Honor 2005-10-26 14:06:28 UTC
When branching, slide add one or to number (depending the version) to the 
version number. 
1.3 become 1.3.1 or 1.3.1.0

In the RDBMS stores, the method "public NodeRevisionDescriptors 
retrieveRevisionDescriptors(Connection connection, Uri uri)" call the method 
"String convertRevisionNumberToComparable(String revisionNumber)" to generate 
the orderby part of the sql query. 

This method generate an sql expression which cut the revision number in two part 
(cutted at the first '.' found) and transform them into number.

"1" is a valid integer and "3.1" is a valid decimal value. but when "1.3.1.0" is 
 split into "1" and "3.1.0", RDBMS can not convert the string "3.1.0" to a valid 
number. en then depending of the database this crach the query, or just 
evaluated as NULL (then the row is misplaced) or the row is skipped.

In all case the revision 1.3.1.0 is never found.
Comment 1 Rob Nielsen 2005-11-18 01:53:09 UTC
We can reproduce this bug too.  Using an Oracle database, if we branch a file to
a four digit descriptor, then restart the container and request a REPORT on the
file, an internal server error is returned.  If the container is not restarted,
the database is never queried.

Our solution is the same as that taken by DB2RDBMSAdapter.  We just added a method 

protected String convertRevisionNumberToComparable(String revisioNumber) {
    return revisioNumber;
}

to our RDBMSAdapter, which fixes the issue and seems to have no ill effects.
Comment 2 Honor 2005-11-18 10:23:36 UTC
I think your solution will cause some other problem with two digit minors. Oracle will 
compare string and in string space "1.9" is greater than "1.10". Then Oracle (and any 
other common rdbms) will sort "1.10" before "1.9". And then, Slide will think that the 
version 1.9 is the last version.

The best solution is to sort in the java side of the store with a RevisionNumber 
comparator.
Comment 3 Rob Nielsen 2005-11-21 07:46:02 UTC
You're right.  Some preliminary testing showed it worked and I assumed that if
another store one used it, it must be ok.  Here's my current one, although I
agree that it should be handled in java code.  It basically sorts by the branch,
then major, then minor and seems to work ok.

protected String convertRevisionNumberToComparable(String revisioNumber) {
        return "substr("+revisioNumber+",1,instr("+revisioNumber+",'.',-1,2)-1)," +
              
"to_number(substr("+revisioNumber+",instr("+revisioNumber+",'.',-1,2)+1," +
                
"instr("+revisioNumber+",'.',-1)-instr("+revisioNumber+",'.',-1,2)-1))," +
             
"to_number(substr("+revisioNumber+",instr("+revisioNumber+",'.',-1)+1))";
    }

Comment 4 Honor 2005-11-21 09:26:39 UTC
I agree, but one more time it will not work in ALL case, juste in common case .
.. because, if you branch a branch you will get a revision number with 6 
number. And then, this method will not work any more. Since there is no maximun 
number of number in revision number, a loop is required, and SQL simply can't do 
it.

Personaly, I work actualy on an adaptor for hsqldb, and hsqldb allow the 
definition of sql function which call java static method. This work well when 
performance is not required (functionality-demo-server, debug, ...).
I don't know if Database like Oracle permit this type of thing. but this is not 
a good solution because it is to much database dependent.
Comment 5 Rob Nielsen 2005-11-22 01:28:54 UTC
Hi.  I agree if you want to fully sort the list you need a loop but looking at
the code, the revisions only have to be sorted relative to the branch they are
on, to populate the latestRevisionNumbers hashtable, (ie the last two numbers of
the revision).  You can remove the first line of the method and it will still
work correctly.  In my testing, I tried up to revision 1.5.2.10.1.11.1.12 and
everything worked fine for me.  

You might also be interested in bug 37583, which I found while testing this one.