db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-337) dblook doesn't generate SQL statements for SQL functions.
Date Wed, 08 Jun 2005 22:54:55 GMT
Satheesh Bandaram (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-337?page=comments#action_12313102 ]

> 
> Satheesh Bandaram commented on DERBY-337:
> -----------------------------------------
> 
> Submitted this patch. I do see you have changed RoutineAliasInfo, 
> a serialized java object that is saved in the disk. Please run some 
> soft upgrade tests, to make sure procedures/functions created in 
> 10.0 are still usable in 10.1 in soft upgrade.

Oh, good point.  This never even occurred to me.

> I think new fields and new methods you have added for
> RoutineAliasInfo may still make it compatible with 10.0 versions,
> but we definitely need to check.

I ran a simple check and it LOOKS like things are okay.  But that said, I ran 
the "serialver" executable to check the serialVersionUID of the class, and it 
has indeed changed with my patch--so I'm not sure this is a safe change.

I then went back to my patch and I declared the new field as "transient"; after 
doing that, "serialver" returned the same long int for the RoutineAliasInfo 
before and after my change.  SO, I can either:

1) create another, 1-line patch that declares the new field as transient, OR
2) get rid of the new field altogether and just use "returnType == null" checks 
to accomplish the same thing.  That was how I originally wrote the patch, but 
then I thought it'd be "better" to introduce this new field because it seems 
clearer to read:

if (aliasType == AliasInfo.ALIAS_TYPE_PROCEDURE_AS_CHAR) ...

than

if (returnType == null) ...

But I've added comments to the IF, so I guess either is probably okay...

Any preference?

Thanks for the review,
Army


Mime
View raw message