[
https://issues.apache.org/jira/browse/OPENJPA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224635#comment-17224635
]
Enrico Olivelli commented on OPENJPA-2837:
------------------------------------------
I have tried to perform various fixes, like stripping delimiters in
LazySchemaFactory, or trying to fix the code path from
QualifiedDBIdentifier.newPath to DBDictionary#fromDBName but without success.
If we se useSchemaName in HerdDBDirectory the problem disappear, this is a good
immediate fix for the HerdDBDictionary use case.
Probably a more deep fix would be needed, but I still it is not much clear to
me when we are applying delimiters.
Sometimes (schema generation from Java files?? and DBDictionary#fromDBName) we
are using the default rules (with double quotes) and sometimes (SQL
generation??) we should use DBDictionary delimiters (this is true for toDBName)
> 'native' SchemaFactory (LazySchemaFactory) does not work with DBDictionaries
> that require delimiters (like HerdDBDictionary) and generated column values
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-2837
> URL: https://issues.apache.org/jira/browse/OPENJPA-2837
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 3.1.2
> Reporter: Enrico Olivelli
> Priority: Critical
> Fix For: 3.1.3
>
>
> If you want to enable physical Foreign Keys you have to configure
> SchemaFactory with 'native'.
> In this case the LazySchemaFactory does not handle correctly delimiters and
> everything breaks, even the creation of OPENJPA_SEQUENCE table.
>
> The problem is that the query generated for loading the sequence value is:
> {code:java}
> SELECT `SEQUENCE_VALUE` FROM "herd"."`OPENJPA_SEQUENCE_TABLE`" WHERE `ID` = ?
> FOR UPDATE [params=?]{code}
>
> It is adding default delimiters to the schema name and the tablename.
> the problem is in TableJDBCSeq.java, using LazySchemaFactory the primary
> table name is augmented with the schema name ("herd" in this case) and this
> triggers the 4th case in "resolveTableIdentifier"
>
>
> {code:java}
> public DBIdentifier resolveTableIdentifier(ClassMapping mapping, Table table)
> {
> DBIdentifier sName = mapping.getTable().getSchemaIdentifier();
> DBIdentifier tableName = DBIdentifier.NULL;
> //OPENJPA-2650: Don't use a schema name if the user has requested,
> //via useSchemaName, to not use one.
> if (!_conf.getDBDictionaryInstance().useSchemaName){
> tableName = table.getIdentifier();
> } else if (DBIdentifier.isNull(sName)) {
> tableName = table.getFullIdentifier();
> } else if (!DBIdentifier.isNull(table.getSchemaIdentifier())) {
> tableName = table.getFullIdentifier();
> } else {
> tableName = QualifiedDBIdentifier.newPath(sName, table.getIdentifier());
> }
> return tableName;
> }
> {code}
>
>
> This tracks down to QualifiedDBIdentifier.newPath(sName,
> table.getIdentifier()); that basically does not work when you have compound
> identifiers and delimiters.
> When you are using DynamicSchemaFactory the problem does not arise because we
> fall into case 2h (QualifiedDBIdentifier.newPath(sName,
> table.getIdentifier()) ) and we are not passing by
> QualifiedDBIdentifier.newPath.
>
> The problem is NOT only in QualifiedDBIdentifier.newPath. but it becomes a
> problem when you perform SQLBuffer#append, that in turn calls
> DBDictionary#fromDBName, that tries to add dict specific delimiters (in this
> case with HerdDBDirection the backtick)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
