You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/04/02 18:58:15 UTC

Index already exists exception

I'm using 0.9.6 on hsqldb and am getting exceptions like this  
periodically:

<0|false|0.9.6-incubating>  
org.apache.openjpa.persistence.PersistenceException: Index already  
exists: I_BNJBBTB_A1 in statement [CREATE INDEX I_BNJBBTB_A1 ON  
BEANEJB_MXM_UNI_BTOB] {stmnt 7870505 CREATE INDEX I_BNJBBTB_A1 ON  
BEANEJB_MXM_UNI_BTOB (FK1_FOR_AEJB_MXM_UNI_BTOB)} [code=-23,  
state=S0011]
     at org.apache.openjpa.jdbc.meta.MappingTool.record 
(MappingTool.java:536)
     at  
org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings 
(JDBCBrokerFactory.java:167)
     at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl 
(JDBCBrokerFactory.java:127)
     at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker 
(AbstractBrokerFactory.java:164)
     at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker 
(DelegatingBrokerFactory.java:139)


The problem seems to be a problem with not inspecting the catalog to  
determine if an index is already exists with that name, or if it even  
needs to define the fk constraint at all.  I have OpenJPA managing  
the schema of this application and it successfully creates the table,  
and when the application is redeployed doesn't try to recreate the  
table.

Anyway, is this a know problem with 0.9.6?  Is there a way I can turn  
off the index creation while to avoid this problem?  I tried setting  
this openjpa.jdbc.SynchronizeMappings=buildSchema(ForeignKeys=false)   
but it seemed to have no effect.

Thanks for any help,

-dain

Re: Index already exists exception

Posted by Dain Sundstrom <da...@iq80.com>.
Maybe I'm on crack, but

     openjpa.jdbc.SynchronizeMappings=buildSchema(Indexes=false)

has no effect on 0.9.6 as I still see the "CREATE INDEX" statements  
in the log.  I am confident that my properties are being inspected  
because when I set buildSchema(ForeignKeys=true, Indexes=false,  
IgnoreErrors=true), I still see the CREATE INDEX statements and  
exceptions but exceptions are ignored.

-dain

On Apr 2, 2007, at 10:09 AM, Patrick Linskey wrote:

> Are you able to reproduce this in any fashion? It'd be interesting to
> figure out why OpenJPA was attempting to recreate the indexes.
>
> There are a couple of ways to get around the error:
>
> - set the IgnoreErrors MappingTool flag to true. This will cause any
> errors during schema synchronization to be ignored; presumably, if
> anything fatal goes wrong, you'll get an error later on when OpenJPA
> attempts to send invalid SQL to the database. You can do this like so:
>
>     openjpa.jdbc.SynchronizeMappings=buildSchema(IgnoreErrors=true)
>
> - tell OpenJPA not to build indexes:
>
>     openjpa.jdbc.SynchronizeMappings=buildSchema(Indexes=false)
>
> I got these options from the documentation for the MappingTool,  
> which is
> what OpenJPA invokes when synchronizing mappings.
> (http://incubator.apache.org/openjpa/docs/latest/manual/ 
> manual.html#ref_
> guide_mapping_mappingtool_examples)
>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.
>
>> -----Original Message-----
>> From: Dain Sundstrom [mailto:dain@iq80.com]
>> Sent: Monday, April 02, 2007 9:58 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Index already exists exception
>>
>> I'm using 0.9.6 on hsqldb and am getting exceptions like this
>> periodically:
>>
>> <0|false|0.9.6-incubating>
>> org.apache.openjpa.persistence.PersistenceException: Index already
>> exists: I_BNJBBTB_A1 in statement [CREATE INDEX I_BNJBBTB_A1 ON
>> BEANEJB_MXM_UNI_BTOB] {stmnt 7870505 CREATE INDEX I_BNJBBTB_A1 ON
>> BEANEJB_MXM_UNI_BTOB (FK1_FOR_AEJB_MXM_UNI_BTOB)} [code=-23,
>> state=S0011]
>>      at org.apache.openjpa.jdbc.meta.MappingTool.record
>> (MappingTool.java:536)
>>      at
>> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings
>> (JDBCBrokerFactory.java:167)
>>      at
>> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl
>> (JDBCBrokerFactory.java:127)
>>      at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker
>> (AbstractBrokerFactory.java:164)
>>      at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker
>> (DelegatingBrokerFactory.java:139)
>>
>>
>> The problem seems to be a problem with not inspecting the catalog to
>> determine if an index is already exists with that name, or if
>> it even
>> needs to define the fk constraint at all.  I have OpenJPA managing
>> the schema of this application and it successfully creates
>> the table,
>> and when the application is redeployed doesn't try to recreate the
>> table.
>>
>> Anyway, is this a know problem with 0.9.6?  Is there a way I
>> can turn
>> off the index creation while to avoid this problem?  I tried setting
>> this
>> openjpa.jdbc.SynchronizeMappings=buildSchema(ForeignKeys=false)
>> but it seemed to have no effect.
>>
>> Thanks for any help,
>>
>> -dain
>>
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries   
> and  affiliated entities,  that may be confidential,  proprietary,   
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.


Re: Index already exists exception

Posted by Dain Sundstrom <da...@iq80.com>.
So to restate, without the readSchema option, the mapping tool  
doesn't know the existing index names or which columns have indexes.   
This means that indexes are created blindly, and there could very  
well be an index conflict for an existing table created by OpenJPA.

Assuming that is true, shouldn't we change failed index creation  
without readSchema to a warning instead of an error.

-dain

On Apr 2, 2007, at 10:15 AM, Abe White wrote:

> Note that I don't think OpenJPA reads index names from the existing
> schema by default, so if you're adding fields or classes these might
> be plain old naming conflicts due to truncation based on database
> name length limits.  There is a readSchema option on the mapping tool
> that forces it to read index and foreign key names and so forth, but
> it slows the tool down a lot for some DBs with slow schema reflection.
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries   
> and  affiliated entities,  that may be confidential,  proprietary,   
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.


Re: Index already exists exception

Posted by Abe White <aw...@bea.com>.
Note that I don't think OpenJPA reads index names from the existing  
schema by default, so if you're adding fields or classes these might  
be plain old naming conflicts due to truncation based on database  
name length limits.  There is a readSchema option on the mapping tool  
that forces it to read index and foreign key names and so forth, but  
it slows the tool down a lot for some DBs with slow schema reflection.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

RE: Index already exists exception

Posted by Patrick Linskey <pl...@bea.com>.
Are you able to reproduce this in any fashion? It'd be interesting to
figure out why OpenJPA was attempting to recreate the indexes.

There are a couple of ways to get around the error:

- set the IgnoreErrors MappingTool flag to true. This will cause any
errors during schema synchronization to be ignored; presumably, if
anything fatal goes wrong, you'll get an error later on when OpenJPA
attempts to send invalid SQL to the database. You can do this like so:

    openjpa.jdbc.SynchronizeMappings=buildSchema(IgnoreErrors=true)

- tell OpenJPA not to build indexes:

    openjpa.jdbc.SynchronizeMappings=buildSchema(Indexes=false)

I got these options from the documentation for the MappingTool, which is
what OpenJPA invokes when synchronizing mappings.
(http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#ref_
guide_mapping_mappingtool_examples)

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Dain Sundstrom [mailto:dain@iq80.com] 
> Sent: Monday, April 02, 2007 9:58 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Index already exists exception
> 
> I'm using 0.9.6 on hsqldb and am getting exceptions like this  
> periodically:
> 
> <0|false|0.9.6-incubating>  
> org.apache.openjpa.persistence.PersistenceException: Index already  
> exists: I_BNJBBTB_A1 in statement [CREATE INDEX I_BNJBBTB_A1 ON  
> BEANEJB_MXM_UNI_BTOB] {stmnt 7870505 CREATE INDEX I_BNJBBTB_A1 ON  
> BEANEJB_MXM_UNI_BTOB (FK1_FOR_AEJB_MXM_UNI_BTOB)} [code=-23,  
> state=S0011]
>      at org.apache.openjpa.jdbc.meta.MappingTool.record 
> (MappingTool.java:536)
>      at  
> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings 
> (JDBCBrokerFactory.java:167)
>      at 
> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl 
> (JDBCBrokerFactory.java:127)
>      at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker 
> (AbstractBrokerFactory.java:164)
>      at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker 
> (DelegatingBrokerFactory.java:139)
> 
> 
> The problem seems to be a problem with not inspecting the catalog to  
> determine if an index is already exists with that name, or if 
> it even  
> needs to define the fk constraint at all.  I have OpenJPA managing  
> the schema of this application and it successfully creates 
> the table,  
> and when the application is redeployed doesn't try to recreate the  
> table.
> 
> Anyway, is this a know problem with 0.9.6?  Is there a way I 
> can turn  
> off the index creation while to avoid this problem?  I tried setting  
> this 
> openjpa.jdbc.SynchronizeMappings=buildSchema(ForeignKeys=false)   
> but it seemed to have no effect.
> 
> Thanks for any help,
> 
> -dain
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.