Armin, First off, yes, it does work. Thanks! Feel free to commit to CVS.
Second, I want to apologize. I get frustrated with people at my work that don't attempt to solve their own problems, and it seems that I did the same thing to you. I was on my way out the door from work yesterday when this creeped up in my upgrade to the latest from HEAD. I was in a rush to get an email to the list before I left so you would see it first thing in the morning, and I didn't spend anytime to actually find the solution. As soon as I got home from my commute, I looked at it, and came to the same fix that you did, about 10 minutes before you sent your email out. So, once again, thanks! -Andrew -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 7:04 PM To: OJB Users List Subject: Re: Bug in AbstractSequenceManager found!! Hi Andrew, oops, my fault! I can't test this sequence manager implementation, because I don't use MSSQL. Seems we have to override getUniqueValue method of AbstractSM.. I attached a new version of SequenceManagerMSSQLGuidImpl - hope it will pass the apache server ;-) Can you verify this class? regards, Armin Clute, Andrew wrote: > I recently updated to HEAD of CVS, and it exposed an issue I have > within the AbstractSequenceManager. > > I was the original author of the SequenceManagerMSSQLGuidImpl sequence > manager, with it's goal to be to allow the use of MSSQL's unique > identifier as their primary key. When the SequenceManagerMSSQLGuidImpl > was written, the code inside of AbstractSequenceManager (v 1.10) would > do a check of the JDBC type of the primary key field, and the call the > apporpriate getUniqueX field. > > Because the MSSQL unique identifiers come back best as VARCHAR's (they > look like this '3C6D40F6-F961-49F2-B7F4-BAAA48B8F1F3'), I had them > defiend as varchar's in the repository, and AbstractSequenceManager > would see that and call the getUniqueString() method on the sequence > manager, and all would be fine. Worked like a charm. > > However, the code in AbstractSequenceManager (as of v1.11) now no > longer does that type check, and just assumes that getUniqueLong() > will work and blindly calls that! Opps! That won't work for the > SequenceManagerMSSQLGuidImpl because there is no way to return a long > representation of the GUID string that is returned from MSSQL. > > So, that makes SequenceManagerMSSQLGuidImpl broken, as it has no way > to return a valid PrimaryKey. > > Is this something we should fix, or am I out of luck now with my > SequenceManagerMSSQLGuidImpl? > > Thanks > -Andrew > > > > > --------------------------------------------------------------------- > 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]
