db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: [PATCH](DERBY-573) Provide support for optimizer overrides in Derby
Date Wed, 07 Dec 2005 07:26:22 GMT
Hi Everyone,

Here is the updated patch information which includes optimizer overrides
support and database upgrade code. I have attached the patch to the Jira
entry.

The code for optimizer overrides support is same as for the earlier patch.
But since the metadata.properties has changed between 10.1 and 10.2 (because
of the new user visible optimizer overrides syntax), we need to have proper
upgrade code to support this change.

Following is a brief description of upgrade code
1)If a 10.1 db is getting run in soft upgrade mode with 10.2, the system
tables would still have the old 10.1 optimizer overrides syntax which is not
recognized by 10.2 The system tables of the 10.1 db can't be modified in
soft upgrade mode to store the new 10.2 optimizer overrides syntax for
metadata queries because in soft upgrade, system tables can't be modified in
a backward incompatible way. To get around this, I have changed the code in
EmbedDatabaseMetaData.java to see if db is getting run in soft upgrade mode.
If yes, then it should read the metadata queries from
metadata.propertiesrather than system tables. This will work because
metadata.properties for 10.2 release has been modified to use the new
optimizer overrides syntax.

2)If a 10.1 db is getting run in hard upgrade mode with 10.2, then we can
simply drop the stored queries for metadata calls from system tables and put
new queries from metadata.properties into the system table. This is
acceptable in hard upgrade, because 10.2 db is not expected to run in
10.1release. This code is in DD_version.java

3)I have implemented the above 2 upgrade modes in a generic mode such that
in future, with every new release, in soft upgrade mode, we will always read
the metadata queries from metadata.properties. And in hard uprgade mode, we
will drop and recreate the stored metadata queries in the system tables with
the latest metadata queries from metadata.properties. This will take care of
any future metadata.properties changes between the releases.

A little description on changes made to some of the java files for the
upgrade code
1)Added new methods in Statement.java and
LanguageConnectionContext.javawhich will allow us to recognize the
queries coming from metadata calls and
let such queries use internal SQL syntax. These internal SQL syntaxes are
not available to an end user but we have some queries in
metadata.propertieswhich rely on them and hence we need to be able to
run these queries with
their internal syntax. This was not required in the past because metadata
calls were always run from the system tables and hence the internal syntax
was available to metadata calls at that point. Now, that in soft upgrade
mode, we read the queries from metadata.properties file, we need to add
these special methods to recognize metadata queries as special internal
queries and let them use internal SQL syntax.
2)In DataDictionary.java, I have added 2 final static variables. One is
added to reflect the 10.2 db version, DD_VERSION_DERBY_10_2. The other one
is DD_VERSION_THIS_SOFTWARE_VERSION and with every release, it should be
updated to the latest DD version final static number. This variable will be
used by EmbeddedDatabaseMetaData to determine if we are in soft upgrade
mode. Rather than hardcoding 10.2 DD version in EmbeddedDatabaseMetaData, I
thought it would be better to use a generice variable
DD_VERSION_THIS_SOFTWARE_VERSION.

In order to test my upgrade changes, I have used
derbyTesting/upgradeTests/phaseTester.java which was checked in by Dan
sometime back. I have changed this test to be a subclass of
metadata.javaand then I run the existing metadata tests within
phaseTester after various
stages of upgrade on a 10.1 db. phaseTester takes 4 parameters, the old
derby major version, old derby minor version, old engine
derby.jarclasspath, new engine
derby.jar and derbyTesting.jar classpath. An eg run is as follows
$
C:/p4clients/main/opensource/java/testing/org/apache/derbyTesting/upgradeTests/runphases
10 1 c:/p4clients/code101/opensource/jars/sane
c:/p4clients/main/opensource/jars/sane
For the command above, phaseTester will
1)first create a 10.1 db and then will run metadata tests on it.
2)Then run the 10.1 db with 10.2 software in soft upgrade mode and run the
metadata tests on it (this is where the metadata sql will be picked from
metadata.properties rather than system table)
3)The run the soft upgraded 10.1 db back with 10.1 software and rerun the
metadata tests
4)Now run the 10.1 db in hard upgrade mode with 10.2 software. The db will
be upgraded to 10.2 version (which means that stored metadata sql from
system tables will be dropped and recreated with sql from
metadata.properties). Run the metadata tests on this hard upgraded db
5)Finally, try to use this upgraded 10.2 db with 10.1 software and that will
fail because we don't have backward compatibility.

This phaseTester test unfortunately is not part of derbyall and has to be
run manually. I think we have a beetle entry Derby-514 to make this test
available as part of a suite rather than requiring manual runs.

One another note on the tests, I have merged metadataJdbc20 and
metadata.java into one single test by moving all the tests from
metadataJdbc20 to metadata.java's super class metadata_test.java. In the
past when we had support from jdk18, we had to have a separate
test for jdbc20 but since jdk18 support has been phased out, these tests can
be merged.

Also, for reference, I have included the comments for the actual optimizer
overrides changes from the previous patch.
Majority of the changes went into the sqlgrammar.jj because Derby engine
already has support for them internally. It is the parser that needs to
recognize these overrides and pass it on to through the query nodes. The
parser now looks for character sequence -- DERBY-PROPERTIES (case
insensitive and space between -- and D is optional) and once it finds that,
it looks for propertyName=value pairs on that same comment line in parser's
propertyList method. The parser does the basic check to make sure that the
same property is not used more than once for a given table. The remaining
checks on the properties like checking the existence of user specified index
etc are done in the bind phase.

I also changed the metadata.properties file to use --DERBY-PROPERTIES rather
than old PROPERTIES clause to supply optimizer overrides. In addition, added
\n at the end of the optimier override comment lines to make sure the
comment line does not get concatenated with the next line of the sql.

Import.java had to be changed to user --DERBY-PROPERTIES rather than
PROPERTIES.

Added a new test optimizerOverrides.sql which runs in both embedded and
network server mode.

Finally, I have run the derbyall suite and these changes didn't cause any
new failures.

Please review and send in your comments.
Mamta
On 12/6/05, Satheesh Bandaram <satheesh@sourcery.org> wrote:
>
> Great! It will be interesting to see how you are handling soft and hard
> upgrades. I will wait for the new patch to start the review.
>
> Satheesh
>
> Mamta Satoor wrote:
>
> Thanks, Satheesh, for the update. But I am very close to submitting a new
> patch for this functionality which will also include soft and hard upgrade
> to 10.2 So, give me a day or two to submit the new patch and then you
> (and anyone else who might be interested) can review that patch.
>
> thanks,
> Mamta
>
>
> On 12/6/05, Satheesh Bandaram <satheesh@sourcery.org> wrote:
> >
> > Hi Mamta,
> >
> > I will review with the goal of committing this patch this week. THANKS
> > for being patient... I was held up trying to get my GrantRevoke Part I patch
> > out last few weeks.
> >
> > Satheesh
> >
> > Mamta Satoor wrote:
> >
> > Hi Everyone,
> >
> > I posted this patch about 20days back. Does anyone have any feedback on
> > the patch? Is it good to go?
> >
> > thanks,
> > Mamta
> >
> >
> > On 11/8/05, Mamta Satoor <msatoor@gmail.com> wrote:
> > >
> > > Hi Everyone,
> > >
> > > I have the patch for optimizer overrides support in Derby. Alongwith
> > > the patch, I have attached the updated functional spec to the JIRA
> > > entry Derby-573.
> > >
> > > Majority of the changes went into the sqlgrammar.jj because Derby
> > > engine already has support for them internally. It is the parser that needs
> > > to recognize these overrides and pass it on to through the query nodes.
> > > The parser now looks for character sequence -- DERBY-PROPERTIES (case
> > > insensitive and space between -- and D is optional) and once it finds that,
> > > it looks for propertyName=value pairs on that same comment line in parser's
> > > propertyList method. The parser does the basic check to make sure that the
> > > same property is not used more than once for a given table. The remaining
> > > checks on the properties like checking the existence of user specified
> > > index etc are done in the bind phase.
> > >
> > > I also changed the metadata.properties file to use --DERBY-PROPERTIES
> > > rather than old PROPERTIES clause to supply optimizer overrides. In
> > > addition, added \n at the end of the optimier override comment lines
> > > to make sure the comment line does not get concatenated with the next line
> > > of the sql.
> > >
> > > Import.java had to be changed to user --DERBY-PROPERTIES rather than
> > > PROPERTIES.
> > >
> > > Added a new test optimizerOverrides.sql which runs in both embedded
> > > and network server mode.
> > >
> > > Rerunning all the tests after syncing the codeline to make sure
> > > nothing has broken. An earlier run of the tests before the sync came out
> > > clean.
> > >
> > > I plan to next work on exposing these overrides through runtime
> > > statistics so that user can verify that the optimizer overrides are
> > > getting used.
> > >
> > > I haven't researched into upgrade much but will the changes in
> > > metadata.properties require some upgrade path for existing databases?
> > > Any pointers here will be very useful.
> > >
> > > svn stat
> > > M      java\engine\org\apache\derby\impl\load\Import.java
> > > M      java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
> > > M      java\engine\org\apache\derby\impl\jdbc\metadata.properties
> > > M      java\engine\org\apache\derby\iapi\reference\SQLState.java
> > > M      java\engine\org\apache\derby\loc\messages_en.properties
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\tests\lang\db2Compatibility.sql
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\tests\lang\copyfiles.ant
> > > A
> > > java\testing\org\apache\derbyTesting\functionTests\tests\lang\optimizerOverrides.sql
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\tests\lang\checkConstraint.sql
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\tests\store\access.sql
> > > A
> > > java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\optimizerOverrides.out
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\master\db2Compatibility.out
> > > A
> > > java\testing\org\apache\derbyTesting\functionTests\master\optimizerOverrides.out
> > >
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\master\checkConstraint.out
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\master\access.out
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall
> > > M
> > > java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
> > >
> > > Comments/questions on the patch?
> > > thanks,
> > > Mamta
> > >
> >
> >
>

Mime
View raw message