db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: upgrade and compiled statements in SYSSTATEMENTS - question
Date Mon, 30 Apr 2007 10:07:51 GMT
Mike Matrigali <mikem_app@sbcglobal.net> writes:

> Knut.Hatlen@Sun.COM wrote:
>> Mike Matrigali <mikem_app@sbcglobal.net> writes:
>>>My assumption for both soft and hard upgrade on changes to
>>>objects in compiled parts of queries was that I did not have
>>>to worry about upgrade.  That any change to query plan data
>>>structures stored on disk would be taken care of automatically
>>>by just dropping them on any release number change.
>>>Is that valid?
>> If you by "any release number change" mean change of major or minor
>> release number, yes. On soft upgrade, the queries will be read directly
>> from org/apache/derby/impl/jdbc/metadata.properties or
>> org/apache/derby/impl/sql/catalog/metadata_net.properties. On hard
>> upgrade, the statements in SYSSTATEMENTS will be dropped, re-read from
>> metadata(_net).properties and recompiled.
>> There are some more details on the wiki:
>> http://wiki.apache.org/db-derby/MetadataUpgrade
> Thanks for the pointer.  From the wiki it seems like we don't drop
> SYSSTATEMENTS for soft upgrade.

That's correct. We don't drop them since we want to be able to go back
to the old version without needing any downgrade code.

> It also sounds like we prevent reads
> from SYSSTATEMENTS for soft upgrade.

Yes, since the queries might have been changed between the versions we
cannot use the old ones in SYSSTATEMENTS.

> Is there meant to be something
> preventing writes to SYSSTATEMENTS for soft upgrade (ie. is there
> anything preventing recompile from updating SYSSTATEMENTS)?

To my knowledge, there is nothing that prevents writes to SYSSTATEMENTS
(except the mechanism that prevents metadata calls from using it), but I
thought SYSSTATEMENTS was only written to during database creation and
hard upgrade. And recompiles shouldn't happen as long as the metadata
calls don't use the stored statements, right? There could of course be
code (even user code) that executes the statements directly, but I'm not
aware of any part of the Derby code doing that.

Knut Anders

View raw message