[
https://issues.apache.org/jira/browse/DERBY-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402305#comment-13402305
]
Rick Hillegas commented on DERBY-5818:
--------------------------------------
What Saurabh needs is the version level of the on-disk data, not the version
level of derby.jar. Note that DatabaseMetaData.getDatabaseProductVersion()
returns the version level of derby.jar, not the version level of the on-disk
data.
Before continuing this discussion, people may want to read the description of
Derby version identifiers found here:
http://db.apache.org/derby/papers/versionupgrade.html.
At database creation time, Derby does save the on-disk version as a DD_Version
object in the properties conglomerate. This object can be looked up with the
key 'DataDictionaryVersion'. The DD_Version object preserves almost all of the
version information, although in a tricky encoded format. More specifically,
the DD_Version object preserves the full four part major.minor.fixpack.point id
plus the beta flag. However, the subversion codeline stamp is not preserved.
Unfortunately, most of this information is clobbered if you boot the database
with a higher version than the one which created it. Only the major.minor part
of the id is preserved. The fixpack, point, and beta information are lost. The
clobbering is done by the following code block in
DD_Version.handleMinorRevisionChange(). This code has been part of Derby since
it was open-sourced:
if (softUpgradeRun)
{
// log a version that will cause a minor
revision change
// for any subsequent re-boot, including an old
Cloudscape version
fromVersion.minorVersionNumber = 1; // see
getJBMSMinorVersionNumber
lastRun = fromVersion;
}
...
tc.setProperty(DataDictionary.CORE_DATA_DICTIONARY_VERSION, fromVersion, true);
So if you boot a 10.5.1.1 database using a 10.8.2.2 derby.jar, the database
will be silently transformed from the 10.5.1.1 format into a generic 10.5
format. Derby itself will not be able to figure out if the database was created
by 10.5.1.1 or 10.5.2.0 or 10.5.3.0.
Note the following additional subtlety: If you boot a database with a lower
version of derby.jar than the one which created the database (but still in the
same major.minor release family), then the DD_Version information is NOT
clobbered. E.g., if you boot a 10.8.2.2 database with 10.8.1.2, then the
on-disk version of the data remains at level 10.8.2.2.
An additional subtletly is that the DD_Version object is also not clobbered in
a read-only database. So if you create a database with version 10.5.1.1, put it
in a jar file, and then boot the jar'd database using 10.8.2.2, the jar'd
database remains at version 10.5.1.1.
To summarize:
a) If you boot a read/write database with a later version of Derby than the one
used to create the database, then the database is silently transformed to a
generic on-disk format, losing all version information other than the generic
major.minor number returned by "values
syscs_util.syscs_get_database_property('DataDictionaryVersion')".
b) This transformation does not happen if you boot the database with an earlier
version of Derby than the one used to create the database. The transformation
is also not performed on read-only databases.
But, in general, the very act of inspecting a database may transform it into a
generic format. There is no general solution to the problem posed by Saurabh.
You cannot count on the on-disk format being anything more specific than the
generic major.minor version returned by "values
syscs_util.syscs_get_database_property('DataDictionaryVersion')".
Follow-on questions for Saurabh would be:
i) Why is the 2 part version level (major.minor) of the on-disk data not
adequate?
ii) What breaks if you only have a 2 part data version rather than a four part
data version (major.minor.fixpack.point)?
Thanks,
-Rick
> values syscs_util.syscs_get_database_property('DataDictionaryVersion' ) does
> not return full version information
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5818
> URL: https://issues.apache.org/jira/browse/DERBY-5818
> Project: Derby
> Issue Type: Bug
> Reporter: Saurabh Kejriwal
>
> Details
> ------------
> $ ./sysinfo
> ------------------ Java Information ------------------
> Java Version: 1.6.0
> Java Vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre
> Java classpath:
> /scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derby.jar:/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derbynet.jar:/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derbytools.jar:/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derbyclient.jar
> OS name: Linux
> OS architecture: i386
> OS version: 2.6.18-164.0.0.0.1.el5xen
> Java user name: ansverma
> Java user home: /home/ansverma
> Java user dir: /scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/bin
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> java.runtime.version: 1.6.0-b09
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derby.jar] 10.8.2.2 -
> (1181258)
> [/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derbytools.jar]
> 10.8.2.2 - (1181258)
> [/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derbynet.jar] 10.8.2.2
> - (1181258)
> [/scratch/ansverma/JavaDBnew/db-derby-10.8.2.2-bin/lib/derbyclient.jar]
> 10.8.2.2 - (1181258)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale : [English/United States [en_US]]
> Found support for locale: [cs]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [de_DE]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [es]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [fr]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [hu]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [it]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ja_JP]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ko_KR]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [pl]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [pt_BR]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ru]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [zh_CN]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [zh_TW]
> version: 10.8.2.2 - (1181258)
> ------------------------------------------------------
> Description
> -----------------
> I am using Derby 10.8.2.2. I want to get derby version details through SQL. I
> ran following query to retrieve version information.
> $ java -jar
> /scratch/ansverma/JavaDBnew//db-derby-10.8.2.2-bin/lib/derbyrun.jar ij
> ij version 10.8
> ij> CONNECT 'jdbc:derby:test2;user=test2;password=test2';
> ij> values syscs_util.syscs_get_database_property('DataDictionaryVersion');
>
> 1
>
> --------------------------------------------------------------------------------------------------------------------------------
> 10.8
>
> 1 row selected
> It did not return full version information (10.8.2.2) for Derby.
> Expected result = 10.8.2.2
> Actual result = 10.8
> I want the version details through SQL query.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
