AbtIbmCliFixedCharField and GLORP

Hi Joachim,

I have noticed this behavior as well, with and without GLORP.  I am currently working on the GLORP code in VA Smalltalk, so I will open a case to look into this issue in more depth.  I agree that a new setting could be introduced to determine the behavior of CHAR(1) fields, and that it needs to default to Character to allow existing code to function asis.  Furthermore, when GLORP code is active, it probably should always be treated as a String instead of a Character, to remain compatible with GLORP.

Thanks,

Bob  Brodd

On Tuesday, March 6, 2012 3:01:05 AM UTC-5, [hidden email] wrote:

I just stumbled upon a problem with GLORP and its TypeResolvers that use a CHAR(1) field for subclass determination.

GLORP handles CHAR(1) aus Strings, and AbtIbmCliFixedCharField handles fixed Chars as Characters if the String returned from the DB is of length 1. This causes GLORP to throw errors when trying to read objects from the DB because there is no key for the Character.

Example: I have a TypeResolver that saves 'P' for a subclass as type discriminator. When a row is read from the DB, GLORP needs to determine what class to instantiate and fill with values. Unfortunately, AbtIbmCliFixedCharField returns the character $P instead of the String 'P', so Glorp cannot determine the class to instantiate because there's no entry for $P in the type dictionary.

I tried to find a good place to fix that, but neither in the VAST DB code nor in Glorp did I really find a place that seems to be harmless to other code. especially in the case of AbtIbmCliFixedCharField I see a big danger of breaking lots of existing code. I guess a good portion of existing VAST Applications that use DB2 rely on the fact that CHAR(1) fields are converted to Characters instead of Strings. Since I have to power to change my DB schema, I solved this by making it a CHAR(2) column and have no problems any more, but not everybody may be in that comfortable position.

So what I'd like to suggest is some kind of setting that defaults to Character conversion and can be changed to Strings of size 1 for the DB2 CLI Database framework. (Or did I even overlook one?)

That way no existing code would break and we could make the behavior of VASTs DB2 code a bit more Glorp Friendly and even more predictable to new users. I haven't checked whether the Oracle Counterpart works the same way or not, I only know that in case of ODBC and Access, the problem didn't exist (because I had been using Access for the very same code for quiet a while now).

So what do others think?

P.S: a few more details about my Access to DB2 porting efforts can be found on my blog: http://joachimtuchel.wordpress.com/2012/03/05/dont-use-glorp-type-resolvers-with-char1-fields-in-db2-on-va-smalltalk/