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]
