db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5818) values syscs_util.syscs_get_database_property('DataDictionaryVersion' ) does not return full version information
Date Wed, 27 Jun 2012 15:49:44 GMT

    [ 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

        

Mime
View raw message