On Feb 4, 2008, at 6:14 PM, Patrick Linskey wrote:
So, as a "best practice" for dealing with joined inheritance, have no
cacading deletes for FKs in the db schema?
Does your metadata (annotations and XML) identify that you've got a
cascading constraint on that table?
I looked through the spec, and couldn't find a way to do that - I know
how to define cascade in terms of entities, but this isn't that.
I would expect that if such
metadata exists, or if you tell OpenJPA to ask the DB for such
metadata (and it reports it properly), then your current code would be
fine.
Yeah, I thought I was asking OpenJPA to read the schema :
<bean id="emf"
class
="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="jpaVendorAdapter" ref="jpaVendor" />
<property name="persistenceUnitName" value="pu" />
<property name="persistenceXmlLocation"
value="classpath:persistence.xml"/>
<property name="jpaPropertyMap">
<map>
<entry key="openjpa.jdbc.SchemaFactory"
value="native(ForeignKeys=true)"/>
</map>
</property>
</bean>
-Patrick
On Feb 4, 2008 2:31 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
That was my conclusion too, but I thought that when I was looking at
the SQL logging, that wasn't the case.
So, as a "best practice" for dealing with joined inheritance, have no
cacading deletes for FKs in the db schema?
geir
On Feb 4, 2008, at 2:43 PM, Patrick Linskey wrote:
It sounds like OpenJPA is issuing delete statements for both tables,
but the cascade constraint from the first delete is causing the
second
row to be deleted before the second delete statement is evaluated.
So,
when the dependent row to be deleted is not found, OpenJPA assumes
that this is because a different transaction deleted the record.
-Patrick
On Feb 3, 2008 3:02 PM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Single threaded code, 1 tx, my machine, no else one around...
Code :
/*
* first _delete_ the ones we have
*/
for (ShowInsertionPoint ip : list) {
OMUtil.getEntityManager().remove(ip);
}
OMUtil.getEntityManager().flush();
Exception in thread "main" <openjpa-1.0.1-r420667:592145 fatal
store
error> org.apache.openjpa.persistence.OptimisticLockException:
Optimistic locking errors were detected when flushing to the data
store. The following objects may have been concurrently modified
in
another transaction: [com.joost.model.ShowInsertionPoint-4590,
com.joost.model.ShowInsertionPoint-4593]
at
org
.apache
.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:
2104)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:
1852)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1623)
at
org
.apache
.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:
973)
at
org
.apache
.openjpa
.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:
488)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun
.reflect
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.orm.jpa.SharedEntityManagerCreator
$
SharedEntityManagerInvocationHandler
.invoke(SharedEntityManagerCreator.java:180)
at $Proxy8.flush(Unknown Source)
at
com
.joost
.md
.tools
.importexport
.fields
.show
.ShowInsertionPointsField
.internalModify(ShowInsertionPointsField.java:
209)
Note, that I'm not explicitly using optimistic locking.
A ShowInsertionPoint is a sub of InsertionPoint, using joined
inheritance.
The tables :
CREATE TABLE InsertionPoint (
id int(11) unsigned NOT NULL auto_increment,
itemType varchar(64) collate ascii_bin NOT NULL COMMENT 'The name
of the table that defines any subclass information.',
insertionTime int(8) unsigned NOT NULL COMMENT 'in milliseconds',
sourceCode int(4) unsigned NOT NULL default '1',
quality float unsigned default NULL COMMENT 'Percentage (from 0.0
to 100.0) giving a (human) estimate of how well this insertion
point
is placed wrt the content.',
PRIMARY KEY (id),
KEY InsertionPoint_sourceCodeIndex (sourceCode),
CONSTRAINT InsertionPoint_sourceCodeFK FOREIGN KEY (sourceCode)
REFERENCES InsertionPointSourceCode (`code`)
) ENGINE=InnoDB AUTO_INCREMENT=35960 DEFAULT CHARSET=ascii
COLLATE=ascii_bin;
CREATE TABLE ShowInsertionPoint (
id int(11) unsigned NOT NULL,
showId int(11) unsigned NOT NULL,
PRIMARY KEY (id),
KEY ShowInsertionPoint_showIdIndex (showId),
CONSTRAINT ShowInsertionPoint_idFK FOREIGN KEY (id) REFERENCES
InsertionPoint (id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT ShowInsertionPoint_showIdFK FOREIGN KEY (showId)
REFERENCES VideoShow (id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=ascii COLLATE=ascii_bin;
The whole problem went away when I removed the constraint :
CONSTRAINT ShowInsertionPoint_idFK FOREIGN KEY (id) REFERENCES
InsertionPoint (id) ON DELETE CASCADE ON UPDATE CASCADE,
from ShowInsertionPoint.
Am I doing something wrong? Or is there a bug in OpenJPA?
tia
geir
--
Patrick Linskey
202 669 5907
--
Patrick Linskey
202 669 5907
