Clute, Andrew wrote:
Armin,
First off, yes, it does work. Thanks! Feel free to commit to CVS.
cool, so I will do a check in
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.
Aren't we all human being ;-)
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!
No problem, thank you for support OJB!
regards, Armin
-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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
