Return-Path: Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm Delivered-To: mailing list ojb-dev@db.apache.org Received: (qmail 22465 invoked from network); 7 Mar 2003 17:49:07 -0000 Received: from smtp01.web.de (HELO smtp.web.de) (217.72.192.180) by daedalus.apache.org with SMTP; 7 Mar 2003 17:49:07 -0000 Received: from dialin-145-254-090-188.arcor-ip.net ([145.254.90.188] helo=web.de) by smtp.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE(Exim) 4.97 #53) id 18rLxy-0005jU-00 for ojb-dev@db.apache.org; Fri, 07 Mar 2003 18:49:07 +0100 Message-ID: <3E68DB9A.3030200@web.de> Date: Fri, 07 Mar 2003 18:49:14 +0100 From: Thomas Mahler Reply-To: thma@apache.org Organization: Apache Foundation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OJB Developers List Subject: Re: [OJB] Issue #OJB136 modified [VOTE] References: <3E677672.20405@gmx.ch> <3E679BA5.90300@web.de> <3E68C64D.4090706@gmx.ch> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: thma32@web.de X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi again Jakob, Jakob Braeuchi wrote: > hi thomas, > > i like the approach that SeqMan does NOT do any conversions. imo > returning Object (or String) should be sufficient to cover all > requirements. Ok. Now we only have to solve one issue. Say SeqMan only returns (say) String. And we have defined a (say) MyType2Long conversion (so the column jdbc-type="BIGINT"). This would cause a problem, as the MyType2Long will fail if fed with a String value! Unfortunately there is no way to see what input-type is expected by MyType2Long.sql2java(). The input parameter is just declared as Object. But the SeqMan could use the jdbc-type="BIGINT" information to generate the required Long value. Once SeqMan feeds a Long value into the MyType2Long conversion everything is fine. SO my proposal is now: 1. The seqman must not try to do any field-conversion on its own. 2. It must produce values that comply with the fieldconversions defined for the attribute in question. 3. To be able to do so the generated values must match to the jdbc-type of the attribute in question. I think going this way will provide maximum flexibility while strictly sticking to the normal OJB field-conversion mechanism. cheers, Thomas > > jakob > > Thomas Mahler wrote: > >> Hi Jakob, >> >> Jakob Braeuchi wrote: >> >>> hi thomas, >>> >>> this leads to the problem i described in an earlier post: >>> >>> the field is defined as Long (java-side) and has a FieldConversion >>> sql-Int to java-Long. due to type Long the sequenceManager wil >>> return Long which is not accepted by FieldConversion looking for >>> Integer. >> >> >> >> I we follow my approach we would say that the current solution of the >> SeqMans to detect the needed type causes a problem. >> It's a mixture of concerns, as the SeqMan does type conversions that >> are done by FieldConversions for all other attributes. >> >> We could decide that we only use SeqMan.getNextLong() and drop the >> automatic detection of target types. >> Then the user would be responsible to choose the right field-conversion >> to map this Long Value on the target data type of the autoincrement >> field. >> >> does this make sense? >> Thomas >> >> >>> btw. the patch contributed by dave marquard treats autoincremented >>> values as sql but this leads to a failing testcase. >>> >>> jakob >>> >>> Mahler Thomas wrote: >>> >>>> Hi all, >>>> >>>> What about the following: >>>> Let us treat the output of the auoincrement methods as if they just >>>> came >>>> from a ResultSet, that is as 'sql'. >>>> This will make it easy to work with database based sequence managers >>>> too. >>>> It is then easy to apply the normal FieldConversion approach for >>>> autoincremented fields. >>>> >>>> IMO this would only have little impact on existing codebase this way. >>>> >>>> I don't like the idea to have extra functionality in the >>>> FieldConversion >>>> classes for autoincremented fields. >>>> >>>> Did I miss something? >>>> Thomas >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Armin Waibel [mailto:armin.waibel@code-au-lait.de] >>>>> Sent: Thursday, March 06, 2003 4:20 PM >>>>> To: OJB Developers List >>>>> Subject: Re: [OJB] Issue #OJB136 modified [VOTE] >>>>> >>>>> >>>>> Hi Jakob, >>>>> >>>>> ----- Original Message ----- >>>>> From: "Jakob Braeuchi" >>>>> To: "OJB Developers List" >>>>> Sent: Thursday, March 06, 2003 2:31 PM >>>>> Subject: Re: [OJB] Issue #OJB136 modified [VOTE] >>>>> >>>>> >>>>> >>>>> >>>>>> hi armin, >>>>>> >>>>>> you're right the problem occurs when 'autoincrement' and >>>>>> fieldconversions collide. >>>>>> imo a new method (be it autoincrementToJava or whatever) would allow >>>>>> conversion of autoincremented values for those who need it. >>>>>> >>>>> >>>>> >>>>> >>>>> I agree, but you will run in some hassle writing a FiledConversion >>>>> in a case descripted below. >>>>> >>>>> Say we will implement the method >>>>> public Object autoincrementToJava (Object ojb) >>>>> What type is object 'obj' if our pk-field is a user defined one? >>>>> To get the value BrokerHelper called >>>>> broker.serviceSequenceManager().getUniqueObject(fmd); >>>>> The returned object depends on the used sequence >>>>> manager implementation (think in most cases a String representation >>>>> of a long or int value was returned). This is not transparent for the >>>>> user and could cause trouble e.g. when change the SM. >>>>> >>>>> If we adopt such a method these pitfalls should be well documented. >>>>> >>>>> just my 0.02 Euro ;-) >>>>> >>>>> Armin >>>>> >>>>> >>>>> >>>>>> i'm not sure whether we should ban field conversion for >>>>> >>>>> >>>>> >>>>> autoincrement >>>>> >>>>> >>>>>> values, because autoincrement only supports a limited range >>>>> >>>>> >>>>> >>>>> of types. >>>>> >>>>> >>>>>> for maximum flexibility we should allow it by providing a >>>>> >>>>> >>>>> >>>>> new method >>>>> in >>>>> >>>>> >>>>>> FieldConversion and leave the implementation to those who need it ;) >>>>>> >>>>>> just my 0.02 CHF. >>>>>> >>>>>> jakob >>>>>> >>>>>> Armin Waibel wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 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... >>>>> >>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Say we use a class PrimaryKey >>>>>>> >>>>>>> class PrimaryKey >>>>>>> { >>>>>>> private Long key; >>>>>>> public PrimaryKey() >>>>>>> { >>>>>>> ...... >>>>>>> } >>>>>>> as the primary key field of a persistent object and we want >>>>>>> to use autoincrement for that field too. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 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 ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The problem only occurs when someone use 'autoincrement' >>>>>>> and need fieldConversion too, right? >>>>>>> And only in the sql-->java direction? >>>>>>> Seems in that case the SequenceManager/BrokerHelper >>>>>>> be an 'anti-pattern' ;-) >>>>>>> >>>>>>> A compromise that should work in 90% of all cases without >>>>>>> adopt new methods could be to do the field conversion only >>>>>>> in the 'object case'. >>>>>>> ... >>>>>>> // Object >>>>>>> else if (!f.getType().isPrimitive()) >>>>>>> { >>>>>>> // only assign a value if attribute == null >>>>>>> if (f.get(obj) == null) >>>>>>> { >>>>>>> result = >>>>>>> broker.serviceSequenceManager().getUniqueObject(fmd); >>>>>>> // ### here we do field conversion >>>>>> >>>>>> >>>>>> >>>>> to support >>>>> >>>>> >>>>>>> user defined fields >>>>>>> result = >>>>>>> fmd.getFieldConversion().sqlToJava(result); >>>>>>> if (result != null) >>>>>>> The pitfall is the >>>>>>> broker.serviceSequenceManager().getUniqueObject(fmd) >>>>>>> method, because we don't know what type of object the >>>>>>> sequence manager returns. >>>>>>> This depends on the SM implementation >>>>>>> and not on the jdbc-type of the persistent-class field. >>>>>>> >>>>>>> Thus it could be difficult to write a adequate FieldConversion >>>>>>> AND the #sqlToJava(...) method in fact does a 'javaToJava' >>>>>>> conversion, exactly a 'sequenceManagerToJava' conversion. >>>>>>> The same problem arise when we add a new method. >>>>>>> >>>>>>> Conclusion, I think the only transparent way is to document that >>>>>>> autoincrement fields do not support field conversion. Or do I >>>>>>> overlook somthing? >>>>>>> >>>>>>> regards, >>>>>>> Armin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 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: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------- >>>>> >>>>> >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >>> >> >> >> >> --------------------------------------------------------------------- >> 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 > >