Satheesh Bandaram <[EMAIL PROTECTED]> writes:
> Knut Anders Hatlen wrote:
>
>> - if you move from one version to a version with the same major and
>> minor version (say, from 10.1.1.0 to 10.1.2.1), the SPSs are
>> invalidated, but not dropped. This means they will be recompiled,
>> but still use the old SQL code. Hence, changes to an existing
>> query in metadata.properties will not be visible to the users.
>>
>>
> May be I missed some previous messages about this... Are there real
> examples of need to change metadata between maintenance releases?
> Probably to fix specific bugs? I looked at DERBY-1107 and it talks
> about general need to have a mechanism. Don't think I saw any specific
> examples.
I don't think there has been any metadata changes between maintenance
releases, and I suppose bug fixes should be the only changes between
maintenance releases. And I think it is more a downgrade issue than an
upgrade issue. I mean, for upgrade it's no problem if we don't add
upgrade code until a metadata change is made. The problem with this
approach is that we will still use the new query after a downgrade. As
long as the new query doesn't use new functions, new tables or new
syntax (not likely that we will add such things in a maintenance
release, I guess), the only consequence is that the bug is fixed even
after we downgrade.
>>To solve the problem for the last case, there are at least three
>>options:
>>
>> 1) Drop and regenerate SPSs on all version changes.
>>
>> 2) Stop using SPSs (use ordinary prepared statements instead).
>>
>> 3) Instead of modifying an existing query, one could create a new
>> one with a new name.
>>
>>To me, option 1 seems like the best choice.
>>
>>
> I think so too... but I would like to see specific reasons to need this.
> Some concerns are 1) How would this affect read-only databases? If we
> decided to drop them even for maintenance versions or point-releases,
> need to handle read-only dbs
Since we can't drop and regenerate the statements in a read-only
database, we have two options
1) Leave the current behaviour of Derby. That is, metadata bugs
won't be fixed for read-only databases.
2) Make EmbedDatabaseMetaData do the same in read-only upgrade mode
as it does in soft upgrade mode. That is, read metadata queries
from metadata.properties.
Option 1 keeps the bugs, option 2 gives lower run-time performance
even for the unmodified queries.
> 2) Performance considerations. Could we
> instead make it as need arises? Like if version is going from 10.1.2 to
> 10.1.3 (just example) Hopefully these are rare cases.
Is performance a big issue? This will happen once per version
change. I agree that it could be solved when the need arises. See my
comments above.
--
Knut Anders
