syscat schema mismatch

[Lukas Eder]

Hi Espen,

I've noticed you have regenerated the syscat schema. I'm sorry for the trouble you might have had because of the additional fields in generated classes. Apparently the syscat schema has changed between DB2 versions 9.5 and 9.7. Yesterday, I changed some core logic in code generation, and I wanted to test all of it... I forgot to revert my changes to the syscat schema.

That's an issue that would need broader discussion, and I cannot come up with a satisfactory solution (see also ticket https://sourceforge.net/apps/trac/jooq/ticket/109). The question is, how should jOOQ behave when all fields are selected. Should we select all fields from the generated schema, or should we "select *". Both solutions will cause errors, if there is a mismatch between generated code and the database.

While this mismatch might not be a problem for jOOQ client code, it certainly will be for code generation...

Cheers
Lukas

[Espen Strømsnes]

I totally agree with you in that both solutions will cause errors.

As far as I can see it there are 2 possible solutions for the system schemata:
1. Use specific fields when selecting data from system schemata. By using this least common denominator we have full manual control on the system tables
2. Add support for defining which columns to actually generate jOOQ fields for

The second approach is a special one and (only?) applies to system schemata. I think it will cause more errors/problems/bugreports if we allow client users to specify which columns to include when generating client code. The base rule should always be to generate fields for all columns when generating client code.

Regards,
Espen

2010/12/30 Lukas Eder <lukas...@gmail.com>

[Lukas Eder]

Happy New Year, Espen!

There is a third option, actually. We could use DatabaseMetaData
http://download.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html

Unfortunately, that JDBC standard interface is poorly implemented by most drivers. I fail to understand why so many JDBC-drivers only provide partial implementations...

The second approach is a special one and (only?) applies to system schemata. I think it will cause more errors/problems/bugreports if we allow client users to specify which columns to include when generating client code. The base rule should always be to generate fields for all columns when generating client code.

That's what I thought as well. A more fine-grained restriction on code generation will be hard to maintain and handle. I guess we'll just have to live with that and go the way you suggest, by selecting exactly the needed fields. If we do that, we won't have to worry about DB2 meta schema version 9.5 or 9.7

Cheers
Lukas

2011/1/1 Espen Strømsnes <estro...@gmail.com>