db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: upgrade and compiled statements in SYSSTATEMENTS - question
Date Mon, 30 Apr 2007 14:52:33 GMT
Knut Anders Hatlen wrote:
> 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.

SYSSTATEMENTS is also used for the compiled plans for the action 
statements for triggers, thus it can be written to at any time.

Any version number change causes all plans in SYSSTATEMENTS to become 
invalid and require an automatic re-compile.


View raw message