jdbc2.StoreManager2 and key-generators

[jesper.pedersen]

I'm investigating the migration of one of our applications to the 'cmp2.x jdbc2 pm' configuration.

One issue that I've found is that currently all key-generators (jdbc.keygen) doesn't implement the jdbc2.CreateCommand interface and therefore can't be used together with the StoreManager2 implementation.

I see three possible solutions to this:

1) Define a common interface that both StoreManager's can use and port the existing key generators to that interface

2) Create a jdbc2.keygen package that implements key generators for all databases and define them in standardjboss.xml under new names.

3) Let the existing key generators implement CreateCommand and bridge the new methods internally in each class.

Since the interface for jdbc.StoreManager and jdbc2.StoreManager2 are very different I see 2) as best solution currently until a common interface for store managers have been defined. I know it is not a pretty solution, but it will work without messing with existing code.

Comments, thoughts, ideas ?

[aloubyansky]

The second option is ok. Would you like to contribute?

[jesper.pedersen]

Sure.

I'll port the keygen package and create an issue in JIRA - hopefully the work should finished some time next week for inclusion on Branch_4_2 and HEAD.

Thanks for your feedback.

[aloubyansky]

Great! Thanks!

[jesper.pedersen]

There is a bug in JDBCEntityBridge2::getQualifiedTableName().

The method should do the same as the JDBCEntityBridge::getQualifiedTableName() namely

SQLUtil.fixTableName(metadata.getDefaultTableName(), dataSource);

Should the bug be fixed in the constructor (as local variable) or in the method ?

I'm for the fix in the constructor.

[jesper.pedersen]

Looking at the next at the next exception in our trace it seems that jdbc2.AbstractQueryCommand doesn't implement LIMIT/OFFSET functionality such the jdbc.JDBCAbstractQueryCommand does. Correct ?

If so, how should jdbc2.AbstractQueryCommand implement this functionality ?

The interface between the two classes are different, so the OFFSET/LIMIT information isn't directly available.

[aloubyansky]

"jesper.pedersen" wrote:
There is a bug in JDBCEntityBridge2::getQualifiedTableName().

The method should do the same as the JDBCEntityBridge::getQualifiedTableName() namely

SQLUtil.fixTableName(metadata.getDefaultTableName(), dataSource);

Should the bug be fixed in the constructor (as local variable) or in the method ?

I'm for the fix in the constructor.

Yes, in the ctor or init.

[aloubyansky]

"jesper.pedersen" wrote:
Looking at the next at the next exception in our trace it seems that jdbc2.AbstractQueryCommand doesn't implement LIMIT/OFFSET functionality such the jdbc.JDBCAbstractQueryCommand does. Correct ?

If so, how should jdbc2.AbstractQueryCommand implement this functionality ?

The interface between the two classes are different, so the OFFSET/LIMIT information isn't directly available.

Probably, in a similar way. Seems like static fetchCollection is the place to offset and pass the limit to collectionStrategy.readResultSet(con, ps, rs, factory);

[jesper.pedersen]

Ok -- that is also the way we are looking at it currently.

We will start to submit the patches tomorrow as 3 different issues:

1) QualifiedTableName in EntityBridge2
2) LIMIT/OFFSET functionality in AbstractQueryCommand
3) Key generators for StoreManager2

As they are unrelated (in some way).

Thanks, Alex.

[aloubyansky]

Thanks!

[jesper.pedersen]

The first patches has been submitted.

JBAS-2629 -- updated to provide more fail-safe implementation
JBAS-4339 -- entitybridge2 patch
JBAS-4340 -- key generators patch

The LIMIT/OFFSET patch will be submitted after further internal testing - properly next week.

We will see if we can provide additional key generator implementations - Hsqldb and PostgreSQL have been tested internally.

Thanks for your help Alex.

[jesper.pedersen]

The LIMIT/OFFSET patch has been submitted under JBAS-4408.

Thanks in advance.