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:[EMAIL PROTECTED] 
> 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.

Reply via email to