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?