RE: Index already exists exception
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.
Re: Index already exists exception
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
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:[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.
