[ 
https://issues.apache.org/jira/browse/JCR-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222077#comment-15222077
 ] 

Illia Khokholkov commented on JCR-3956:
---------------------------------------

In the meantime, as a workaround, would it be appropriate to manually execute 
the SQL statement to create a table for the local revisions so that the 
problematic branch of the code never gets hit? I.e., run the following query:
{code:sql}
create table MY_PREFIX_LOCAL_REVISIONS (JOURNAL_ID varchar(255) NOT NULL, 
REVISION_ID number(20,0) NOT NULL);
{code}

> [Oracle 11g, Jackrabbit 2.x] Unable to create local revisions table
> -------------------------------------------------------------------
>
>                 Key: JCR-3956
>                 URL: https://issues.apache.org/jira/browse/JCR-3956
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.11.3
>            Reporter: Illia Khokholkov
>            Priority: Minor
>
> *Background*
> There is an application that was running for a while on Jackrabbit {{1.4.x}} 
> using Oracle database. Recently, it has been decided to consume the {{2.x}} 
> stream of the Jackrabbit.
> *Problem*
> The code base of the solution has been updated to use Jackrabbit {{2.11.3}}. 
> On startup, there is an error that looks like this:
> {noformat}
> Caused by: org.apache.jackrabbit.core.journal.JournalException: Unable to 
> create connection.
>             at 
> org.apache.jackrabbit.core.journal.DatabaseJournal.init(DatabaseJournal.java:278)
>         ...
>         
> Caused by: java.sql.SQLException: Non supported SQL92 token at position: 110
>         at oracle.jdbc.driver.OracleSql.handleODBC(OracleSql.java:1443)
>         ...
> {noformat}
> The problem occurs when Jackrabbit attempts to parse and submit for execution 
> the following SQL statement:
> {code:sql}
> create table ${schemaObjectPrefix}LOCAL_REVISIONS (JOURNAL_ID varchar(255) 
> NOT NULL, REVISION_ID number(20,0) NOT NULL) ${tablespace}
> {code}
> The {{$\{schemaObjectPrefix\}}} gets correctly replaced with the value we 
> defined in the repository configuration, however, {{$\{tablespace\}}} does 
> not get changed to an empty string, which would be the default value for it 
> when it comes to the 
> {{org.apache.jackrabbit.core.journal.OracleDatabaseJournal}}.
> *Cause*
> Consider the following 
> [code|https://github.com/apache/jackrabbit/blob/2.11.3/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/journal/DatabaseJournal.java#L569]:
> {code}
> private void checkLocalRevisionSchema() throws Exception {
>     ...
>     
>     // Run the schema check for the single table
>     new CheckSchemaOperation(conHelper, localRevisionDDLStream, 
> schemaObjectPrefix
>             + LOCAL_REVISIONS_TABLE).addVariableReplacement(
>         CheckSchemaOperation.SCHEMA_OBJECT_PREFIX_VARIABLE, 
> schemaObjectPrefix).run();
> }
> {code}
> It appears that no matter what extension of the 
> {{org.apache.jackrabbit.core.journal.DatabaseJournal}} is in use, there is an 
> assumption that the SQL statement to create a {{<prefix>LOCAL_REVISIONS}} 
> database table will always contain only one variable, i.e. 
> {{$\{schemaObjectPrefix\}}}. As far as I can tell, there is no mechanism to 
> alter this behavior in the subclasses, even though the default one is 
> incorrect when it comes to Oracle.
> *Potential Solution*
> At a minimum, update the 
> [DatabaseJournal|https://github.com/apache/jackrabbit/blob/2.11.3/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/journal/DatabaseJournal.java#L251]
>  in the following manner:
> {code}
> public void init(String id, NamespaceResolver resolver)
>             throws JournalException {
>     ...
>     
>     // Make sure that the LOCAL_REVISIONS table exists (see JCR-1087)
>     if (isSchemaCheckEnabled()) {
>         checkLocalRevisionSchema().run();
>     }
> }
> {code}
> {code}
> protected CheckSchemaOperation checkLocalRevisionSchema() throws Exception {
>     ...
>     
>     new CheckSchemaOperation(conHelper, localRevisionDDLStream, 
> schemaObjectPrefix
>             + LOCAL_REVISIONS_TABLE).addVariableReplacement(
>         CheckSchemaOperation.SCHEMA_OBJECT_PREFIX_VARIABLE, 
> schemaObjectPrefix);
> }
> {code}
> which would align with what was done for 
> [createCheckSchemaOperation()|https://github.com/apache/jackrabbit/blob/2.11.3/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/journal/DatabaseJournal.java#L311]:
> {code}
> protected CheckSchemaOperation createCheckSchemaOperation() {
>     ...
>     
>     return new CheckSchemaOperation(conHelper, in, schemaObjectPrefix + 
> DEFAULT_JOURNAL_TABLE).addVariableReplacement(
>             CheckSchemaOperation.SCHEMA_OBJECT_PREFIX_VARIABLE, 
> schemaObjectPrefix);
>   }
> {code}
> Ideally, {{org.apache.jackrabbit.core.journal.OracleDatabaseJournal}} will 
> need to be updated to override the exposed {{checkLocalRevisionSchema()}} and 
> provide all required substitutions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to