Hi Armin, I thought this line, which we left intact, would handle the long --> String (datatype) field conversion that you mention. return field.getJdbcType().sequenceKeyConversion(new >> Long(getUniqueLong(field)));
Am I wrong about that? The key to the mod that I made was to avoid trying to converting a value that didn't come from the db as if it came from the db. I'm not sure what other cues to use in our impl, other than the fact that it's SequenceManagerTransientImpl being called, which implies that the value did not come from the db. It would be nice if the class to use for this transient case were customizable in OJB.properties. I hate to be modifying OJB, as I know there is so much that it is doing that I do not understand. I could make another check in the modified impl for now, if you're concerned that it could be problematic with other field conversions. I could use the modified logic only when the field conversion is our custom encrypt/decrypt implementation. Thanks so much for the feedback. Any further comments are much appreciated. Ailish -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 4:59 AM To: OJB Users List Subject: Re: Problem w/ SequenceManagerTransientImpl in 1.0.4 Hi, Armin Waibel wrote: >> We encountered a problem with the SequenceManagerTransientImpl. We have >> two objects that are related; bank account has a bank on it. A key to >> the bank account table has a custom FieldConversion implementation for >> encryption/decryption associated with it. When we refresh the >> references on a new bank account, OJB goes to retrieve the bank and uses >> SequenceManagerTransientImpl to initialize any null keys on bank account >> with a unique value. However, after SequenceManagerTransientImpl >> returns a long > 1000, AbstractSequenceManager calls the sqlToJava >> method on the custom FieldConversion (in the getUniqueLong method). The >> custom FieldConversion bombs, because it's being asked to unencrypt and >> already unencrypted value. So, we overrode getUniqueValue in >> SequenceManagerTransientImpl as follows... >> public Object getUniqueValue(FieldDescriptor field) throws >> SequenceManagerException >> { >> return field.getJdbcType().sequenceKeyConversion(new >> Long(getUniqueLong(field))); >> // perform a sql to java conversion here, so that clients do >> // not see any db specific values >> // abyrne commented out: result = >> field.getFieldConversion().sqlToJava(result); >> // abyrne commented out: return result; >> } >> We would appreciate your feedback on whether or not this seems >> problematic. > > The conversion is already done in the super-class > http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/or g/apache/ojb/broker/util/sequence/AbstractSequenceManager.java?view=mark up > > See method #getUniqueValue(...) > This method is called by OJB to lookup the next key. > Damn stupid! Sorry I don't carefully read your question (seems responses written after midnight doesn't contain useful information ;-)). I think it could be problematic to comment out the field conversion. For example, if someone use a long-->String field conversion (with some other modification) for the PK field it's necessary to convert the temporary values. Isn't it possible to differ these temporary values in your field conversion implementation? Would it be useful to make SequenceManagerTransient pluggable, e.g. in the jdbc-connection-descriptor? In this case you could easily use a modified version. regards, Armin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
