> I think, mangling of tablenames does only make sense in the case of > forward engineering when the orm metadata and the SQL schema are generated.
Well, we could just throw a StupidUserException, or we could take remedial action. Not part of the JDO spec so we can do as we please, and we have plenty of other things to do right now. > Currently, you can see this phenomenon when you run the TCK: there are > about 5 errors "Table 'xxx' does not exist", e.g. the classname is > "HashtableStringKeyCollections", the orm metadata maps it to a tablename > "HASHTABLESTRINGKEY_COLLECTIONS" (this tablename is also used in the SQL > schema), but the JPOX generated tablename name is > "HASHTABLESTRINGKEY_COLLET8". As I said yesterday I deleted the code that was limiting it to 25 characters, so you get the full 30 with latest JPOX, with no mangling if your table name is <= 30. So use latest JPOX if that is causing you problems > Another question: The Derby Reference Manual Version 10, June 11, 2005, > specifies that table names in Derby conform to SQL92 indentifiers. SQL92 > identifiers have a max length of 192 unicode characters. So, I'm not > sure about the Derby restriction of 30 characters for identifiers which > you mention above. Derby's JDBC driver (10.0.2.1) returns that it supports 128 characters max for table names, so how that signifies that it supports 192 characters I don't know (probably the difference with the theory (the manual) and practice (the code)). You refer to a particular version of Derby whereas JPOX attempts to work with all versions of Cloudscape. Where the 30 chars table name length in JPOX came from ? you need to ask Erik since he added support for Cloudscape 10+ (aka Derby). I know that I *can* create a table with name of length > 30, so removing the restriction of 30 seems possible, but maybe there's a reason? or maybe this was the limit in Cloudscape 10 before being renamed to Derby ? If there's no good reason then I'll remove the restriction. -- Andy Java Persistent Objects - JPOX
