db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [OJB] Issue #OJB136 modified [VOTE]
Date Thu, 06 Mar 2003 09:01:26 GMT
hi david,

i'm really not sure about conversion of autoIncrement values.

cons:
- the autoincrement value is calculated based on the type of the field 
and thus conversion shouldn't be necessary

pros:
- i'm sure there's at least one case where conversion makes sense...

if we do convert autoIncrement values we'll need an additional method in 
FieledConversion because sqlToJava might fail.
sqlJava is the mehod called when reading from a ResultSet,  so i propose 
to name the new method:

autoIncrementToJava

what do you think ?

jakob

Jakob Braeuchi wrote:

> hi david,
>
> sorry, you're right there's _no_ double conversion. but we have a test 
> case failing after applying this patch.
>
> FieldConversionTest fails because of  conversion :
>
> in BrokerHelper  the autoIncr value in result is _Long_ because of the 
> typ of the field
>
>       result = new 
> Long(broker.serviceSequenceManager().getUniqueLong(fmd));
>       // reflect autoincrement value back into object
>       f.set(obj, fmd.getFieldConversion().sqlToJava(result));
>
> the fieldconversion (inner class FieldConversionLongToInteger) defined 
> for this field checks for _Integer_ which fails:
>
>        public Object sqlToJava(Object source) throws ConversionException
>        {
>            if (!(source instanceof Integer))
>            {
>                throw new ConversionException(
>                        "Wrong java field type when java-->sql, 
> expected java.lang.Integer, found "
>                        + source.getClass());
>            }
>            return new Long(((Integer) source).longValue());
>        }
>
> maybe we should make field conversion more tolerant ???
>
> jakob
>
> David Marquard wrote:
>
>> That's not right! The patch doesn't result in double conversion. The 
>> current
>> (unpatched) code does something like this:
>>
>> result = broker.serviceSequenceManager().getUniqueObject(fmd);
>> // reflect autoincrement value back into object
>> f.set(obj, result);
>>           ^^^^^^
>> As you can see, an *unconverted* object is being retrieved from the 
>> sequence
>> manager and set directly into a persistent field without a field 
>> conversion
>> being run on it. The patch changes that second line to:
>>
>> f.set(obj, fmd.getFieldConversion().sqlToJava(result));
>>
>> which properly converts the object before setting it in the persistent
>> field. The converted object *is not* returned from 
>> getAutoIncrement(), and
>> thus does not cause double conversions. In fact, callers of
>> getAutoIncrement() won't see any difference at all.
>>
>> Dave
>>
>> -----Original Message-----
>> From: Jakob Braeuchi [mailto:jbraeuchi@hotmail.com]
>> Sent: Wednesday, March 05, 2003 8:33 AM
>> To: Dave Marquard
>> Cc: ojb-dev@db.apache.org
>> Subject: [OJB] Issue #OJB136 modified
>>
>>
>>
>> Issue OJB136 has just been modified by user brj
>>
>> You can view the issue detail at the following URL:
>>     <http://scarab.werken.com/scarab/issues/id/OJB136>
>>
>> The following modifications were made to this issue:
>>
>> getAutoIncrement is called be other mehods of BrokerHelper which DO 
>> field
>> conversion.
>> applying this patch results in double conversion. 
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>  
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>


Mime
View raw message