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.
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.
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.
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))"; }
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.
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.