db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: upgrade and compiled statements in SYSSTATEMENTS - question
Date Mon, 30 Apr 2007 18:56:40 GMT


Daniel John Debrunner wrote:
> 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.
In terms of what this means for store, I think this means that the
system is expecting to be able to issue an update of a column where
the current value of the column is "old format" and the new value
of the column is "new format" - but there is no current code that 
understands how to properly read the "old format" in.  Is this the
requirement?  There is no way the current store interfaces commit
to provide this ability, as a side effect it may mostly work.


In general I know
that store can not support this, it is particularly a problem for
btree's. For instance during abort of such
an update store may need to instantiate an instance of both the old
and new columns to compare them.  This definitely happens during
logical undo in btree's.

In specific, it may be that the only need is to support these columns
in heaps, not btrees.
> 
> Dan.
> 
> 
> 


Mime
View raw message