|
Home > Archive > Apache JDO Project > July 2005 > JPOX generated tablenames
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
JPOX generated tablenames
|
|
| Michael Watzek 2005-07-11, 5:45 pm |
| Hi Erik, Andy,
I have question concerning tablenames in SQL statements which JPOX
generates at runtime:
It seems that tablenames which are longer than 25 characters specified
in the orm metadata are mangeled by JPOX runtime. As a consequence, the
database throws a SQLException because the table does not exist.
I understand that many databases restrict SQL identifiers to a length of
30 characters, though SQL92 specifies a max length of 128 characters.
What is the reason, that JPOX mangels tablenames specified in the orm
metadata?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Andy Jefferson 2005-07-11, 5:45 pm |
| > I understand that many databases restrict SQL identifiers to a length of
> 30 characters, though SQL92 specifies a max length of 128 characters.
>
> What is the reason, that JPOX mangels tablenames specified in the orm
> metadata?
Something that had been in the codebase from before its JPOX lifetime and that
I'd meant to remove (so I just did - thanks for reminding me) :-).
Derby accepts table names up to 30 chars in length. If the user specifies
anything longer than 30, the last part of the name is hashed so we limit the
specified tablename to 30 chars. If the user specifies a name of 30 chars or
less then it is now preserved.
--
Andy
Java Persistent Objects - JPOX
| |
| Michael Watzek 2005-07-12, 7:45 am |
| Hi Andy,
>
>
> Something that had been in the codebase from before its JPOX lifetime and that
> I'd meant to remove (so I just did - thanks for reminding me) :-).
>
> Derby accepts table names up to 30 chars in length. If the user specifies
> anything longer than 30, the last part of the name is hashed so we limit the
> specified tablename to 30 chars. If the user specifies a name of 30 chars or
> less then it is now preserved.
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.
In the case, where the orm metadata and the SQL schema are given by the
user, JPOX should not mangle tablenames. Otherwise, you cannot be sure
that there is a suitable table in the database.
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".
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.
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Andy Jefferson 2005-07-12, 7:45 am |
| > 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
| |
| Michael Watzek 2005-07-12, 7:45 am |
| Hi Andy,
I mixed up the max length of SQL92 identifiers: 128 is correct.
Regards,
Michael
>
>
> 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.
>
>
>
>
> 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
>
>
>
>
> 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.
>
>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Michelle Caisse 2005-07-12, 5:45 pm |
| Hi Andy,
At http://www.jpox.org/downloads/nightly/, the last modified date on the
builds is 08-Jul. Is there somewhere that I can get the build with this
change?
-- Michelle
Andy Jefferson wrote:
>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
>
>
>
| |
| Andy Jefferson 2005-07-12, 5:45 pm |
| > At http://www.jpox.org/downloads/nightly/, the last modified date on the
> builds is 08-Jul. Is there somewhere that I can get the build with this
> change?
Hi Michelle,
seems the build hasn't run successfully for the last 3 nights :-(.
I've set it running, so should be updated sometime in the next 30 mins - the
jpox.jar is there now and the enhancer jar will appear soon.
PS It's now being built against the latest API20 jar (the inclusion of
ObjectIdentity)
--
Andy
| |
| erik@jpox.org 2005-07-12, 5:45 pm |
| Quoting Andy Jefferson <andy@jpox.org>:
> 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.
Since Cloudscape is an IBM product, it must be compatible with DB2. Now that
it's under apache they may have removed this limitation.
| |
| Craig Russell 2005-07-12, 5:45 pm |
| | |
| Michelle Caisse 2005-07-12, 5:45 pm |
| Thanks, Andy. This fix lets us get to the next step in some of the
fieldtypes tests.
Now we get an error with collection types where the field is embedded
but jpox is looking for a table for the field:
5)
test(org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections)javax.jdo.JDODataStoreException:
Iteration request failed : SELECT THIS.BIGDECIMAL_ELE FROM
applicationidentity0.COLLECTION_OF_BIG_DECIMAL19 THIS WHERE 1 =
THIS.IDENTIFIER_OID
at
org.jpox.store.rdbms.scostore.AbstractSetStore.iterator(AbstractSetStore.java:143)
at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:247)
at
org.jpox.store.mapping.CollectionMapping.postUpdate(CollectionMapping.java:235)
at
org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266)
at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1795)
at org.jpox.store.StoreManager.update(StoreManager.java:710)
at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:3965)
at
org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:2841)
at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:431)
at
org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:97)
at
org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:203)
at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128)
at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106)
NestedThrowablesStackTrace:
ERROR 42X05: Table 'APPLICATIONIDENTITY0.COLLECTION_OF_BIG_DECIMAL19'
does not exist.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
at
org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java)
at
org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java)
at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java)
at
org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java)
at
org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java)
at
org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java)
at
org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java)
at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java)
at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext. prepareInternalStatement(GenericLanguage
ConnectionContext.java)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedStatement.java)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(EmbedPreparedStatement20.java)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(EmbedPreparedStatement30.java)
at
org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver30.java)
at
org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java)
at
org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java)
at
com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:303)
at org.jpox.store.StatementText.prepareStatement(StatementText.java:236)
at
org.jpox.store.rdbms.scostore.AbstractSetStore.iterator(AbstractSetStore.java:118)
at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:247)
at
org.jpox.store.mapping.CollectionMapping.postUpdate(CollectionMapping.java:235)
at
org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266)
at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1795)
at org.jpox.store.StoreManager.update(StoreManager.java:710)
at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:3965)
at
org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:2841)
at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:431)
at
org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:97)
at
org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:203)
at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128)
at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106)
The .jdo is
....
<field name="CollectionOfBigDecimal19" >
<collection element-type="java.math.BigDecimal" embedded-element="true">
</collection>
....
And the orm:
....
<field name="CollectionOfBigDecimal19"
column="COLLECTION_OF_BIG_DECIMAL19">
</field>
....
-- Michelle
Andy Jefferson wrote:
>
>Hi Michelle,
>
>seems the build hasn't run successfully for the last 3 nights :-(.
>I've set it running, so should be updated sometime in the next 30 mins - the
>jpox.jar is there now and the enhancer jar will appear soon.
>
>PS It's now being built against the latest API20 jar (the inclusion of
>ObjectIdentity)
>
>
>
>
| |
| Craig Russell 2005-07-13, 2:45 am |
| | |
| Andy Jefferson 2005-07-13, 2:45 am |
| > I 'just' looked on the nightly download page and it still has not
> anything later than June 28. Can you verify that I'm looking in the
> right place?
No. You're looking on SourceForge and they kindly changed their systems 2
weeks ago and broke the Maven SourceForge plugin so consequently we can't put
our nightly builds on there at the moment.
Look at
http://www.jpox.org/downloads/latest/
instead.
--
Andy
Java Persistent Objects - JPOX
| |
| Craig Russell 2005-07-14, 2:45 am |
| |
|
|
|
|