db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: changing types and UDT columns
Date Thu, 29 Apr 2010 18:18:22 GMT
Hi Kathey,

Thanks for buddy-testing this feature. Some comments inline...

Kathey Marsden wrote:
> I am starting on the UDT buddy testing and am trying to understand  
> what happens when a  fields change or are added to a class.
>
> What I did was created a Price class with a single double field price, 
> generated the serial version with serialver and then inserted a value 
> into a table.
>
> Then I added a String field for a currencyCode and a function to 
> retrieve it.
>
> I recompiled and tried to regenerate the serialver, which I was 
> surprised stayed the same.
If you hard-coded serialVersionUID, then I would expect that serialver 
would just report that hard-coded value. Note that the javadoc for 
java.io.Serializable recommends the hygienic practice of declaring 
serialVersionUID as private.
>   Then I inserted another row.
> when I selected the currency code from the table, it was all pretty 
> nice, and just said it was NULL for the first object.
> ij> select getCurrencyCode(pr) from items;
> 1
> ----
> NULL
> USD
>
> 2 rows selected
>
> So are changing types all automagical like that or is there typically 
> something that needs to be done as they change?
Your example type evolution is one of the simple cases which the default 
serialization logic knows how to handle: "The version control works 
great as long as the changes are compatible. Compatible changes include 
adding or removing a method or a field. Incompatible changes include 
changing an object's hierarchy or removing the implementation of the 
Serializable interface. A complete list of compatible and incompatible 
changes is given in the Java Serialization Specification." That quote 
comes from this web page: 
http://java.sun.com/developer/technicalArticles/Programming/serialization/

Hope this helps,
-Rick
>
>  Below is the sql and final Price class.  The first version just had 
> the stuff related to currencyCode missing.
>
>
> package com.acme.types;
>
> import java.io.Serializable;
>
> public class Price implements Serializable {
>
>     static final long serialVersionUID = -5418678247307617965L;
>
>     double price = 0;
>     String currencyCode = "USD";
>
>     public Price(double pr) {
>     price = pr;
>     }
>
>     public Price (double pr, String cc) {
>     price = pr;
>     currencyCode = cc;
>     }
>
>
>     public static double getPrice(Price p) {
>     return p.price;
>     }
>
>     public static String  getCurrencyCode(Price p) {
>     return p.currencyCode;
>     }
>
>     public static Price newPrice(double pr) {
>     return new Price(pr);
>     }
>
>
>     public String toString() {
>     return "My price is " +price + "My Currency code is " + currencyCode;
>
>     }
> }
> --------
> connect 'jdbc:derby:wombat;create=true';
> CREATE TYPE price
> EXTERNAL NAME 'com.acme.types.Price'
> LANGUAGE JAVA;
>
> CREATE FUNCTION newprice(pr double)  RETURNS Price  PARAMETER STYLE 
> JAVA NO SQL LANGUAGE JAVA  EXTERNAL NAME 'com.acme.types.Price.newPrice';
>
> CREATE FUNCTION getPrice(pr Price) RETURNS DOUBLE PARAMETER STYLE JAVA 
> NO SQL LANGUAGE JAVA EXTERNAL NAME 'com.acme.types.Price.getPrice';
>
>
> create table items (name LONG VARCHAR, pr Price);
>
> insert into items values('stuffed bear', newprice(2.0));
>
> -- change type to add currencyCode
>
> CREATE FUNCTION getCurrencyCode(pr Price) RETURNS CHAR(3) PARAMETER 
> STYLE JAVA NO SQL LANGUAGE JAVA EXTERNAL NAME 
> 'com.acme.types.Price.getCurrencyCode';
>
>
> select getCurrencyCode(pr) from items;
>
>


Mime
View raw message