Foreign key error if using GenerationType.AUTO or GenerationType.TABLE
Hello, If I use GenerationType.AUTO or GenerationType.TABLE for PK field and let OpenJPA persist some entities cascade , in some cases, OpenJPA will try to persist child entity before the father entity. How to resolve this issue? I must use GenerationType.AUTO for oracle because it doesn't support GenerationType.IDENTITY naturally. Or do I have a chance to use GenerationType.IDENTITY for Pk fields of oracle database? I have attached the log information in attached file. Thanks! Regards, Yu Wang
prepared statement pooling MySQL
Hello list I use OpenJPA with Apache DBCP in Java SE environment. My problem is the performance when prepared statement pooling is enabled in DBCP - it is the same as when statement pooling is disabled. My question is - why prepared statement pooling does not increase performance on MySQL ? BTW I made the same test with PostgreSQL and performance is better when prepared statement pooling is enabled. I use MySQL 5.0.51a and OpenJPA 1.2.0 it is the database configuration in my persistence.xml file. property name=openjpa.ConnectionProperties value=driverClassName=com.mysql.jdbc.Driver, url=jdbc:mysql://localhost:3306/cms8?characterEncoding=UTF-8, username=xxx, password=xxx, maxActive=100, maxIdle=100, initialSize=100, poolPreparedStatements=true/ property name=openjpa.ConnectionDriverName value=org.apache.commons.dbcp.BasicDataSource/ Best regards Georgi
Why is slice module not depended on persistence-jdbc module
Hi, I wanted to know that why is slice module not depended on openjpa-persistence-jdbc module. I was trying to figure out the reason but could not get to anything conclusive. I felt that both persistence and persistence-jdbc module are central to design of openjpa and since there is dependency on persistence module why is there no dependency on persistence-jdbc module. I actually created a test case in slice module and that test case depended on whether JDBCProductDerivation gets loaded or not. Since, slice module has no dependency on persistence-jdbc moule, it doesn't gets loaded. If I move my test case to example module(which has dependency on persistence-jdbc) then test runs fine. It will be really helpful for me if someone can throw some kight on this. thanks and regards -- Ashish Paliwal Mobile : 9305128367 IIT Kanpur India
Re: Why is slice module not depended on persistence-jdbc module
For runtime, Slice only needs access to the jdbc, kernel, and lib jars as it is a BrokerFactory/JDBCProvider. It provides its own ProductDerivation in - src/main/java/org/apache/openjpa/slice/ProductDerivation.java For junit tests, it should only need to include openjpa-persistence for the tests. If other tests are being added that need to use openjpa-persistence-jdbc, then you should ask Pinaki to review your proposed tests. -Donald ashish paliwal wrote: Hi, I wanted to know that why is slice module not depended on openjpa-persistence-jdbc module. I was trying to figure out the reason but could not get to anything conclusive. I felt that both persistence and persistence-jdbc module are central to design of openjpa and since there is dependency on persistence module why is there no dependency on persistence-jdbc module. I actually created a test case in slice module and that test case depended on whether JDBCProductDerivation gets loaded or not. Since, slice module has no dependency on persistence-jdbc moule, it doesn't gets loaded. If I move my test case to example module(which has dependency on persistence-jdbc) then test runs fine. It will be really helpful for me if someone can throw some kight on this. thanks and regards
Problem with @TableGenerator [OpenJPA 1.2.2]
Hello,
Here's my annotation:
@TableGenerator(name = pkGenSessionConfig, table = jdo_keygen,
pkColumnName =
table_name, valueColumnName = last_used_id, pkColumnValue =
session_config, allocationSize
= 10)
@Id
@GeneratedValue(strategy=GenerationType.TABLE,
generator=pkGenSessionConfig)
@Column(name=session_config_id, unique=true, nullable=false)
private int id;
And here's the according SQL generated by OpenJPA:
Unknown column 'TABLE_NAME0' in 'where clause' {prepstmnt 32845046 SELECT
LAST_USED_ID FROM
jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE [params=(String) session_config]}
[code=1054,
state=42S22]
Question: Where does OpenJPA take TABLE_NAME0 from while
pkColumnValue=table_name
Kind Regards,
Michael
Re: Why is slice module not depended on persistence-jdbc module
I suspect that one of Pinaki's design goals with Slice was to make it persistence personality agnostic. So one could use it with a JDO personality as well as a JPA personality (KODO provides both, OpenJPA provides the latter). Slice uses both openjpa-persistence and openjpa-persistence-jdbc for testing though (since no other personalities are available). I imagine if we beefed up the xml module or added a new personality it would be fairly easy for Slice to test with them as well. -mike On Mon, Jun 22, 2009 at 7:13 AM, Donald Woods dwo...@apache.org wrote: For runtime, Slice only needs access to the jdbc, kernel, and lib jars as it is a BrokerFactory/JDBCProvider. It provides its own ProductDerivation in - src/main/java/org/apache/openjpa/slice/ProductDerivation.java For junit tests, it should only need to include openjpa-persistence for the tests. If other tests are being added that need to use openjpa-persistence-jdbc, then you should ask Pinaki to review your proposed tests. -Donald ashish paliwal wrote: Hi, I wanted to know that why is slice module not depended on openjpa-persistence-jdbc module. I was trying to figure out the reason but could not get to anything conclusive. I felt that both persistence and persistence-jdbc module are central to design of openjpa and since there is dependency on persistence module why is there no dependency on persistence-jdbc module. I actually created a test case in slice module and that test case depended on whether JDBCProductDerivation gets loaded or not. Since, slice module has no dependency on persistence-jdbc moule, it doesn't gets loaded. If I move my test case to example module(which has dependency on persistence-jdbc) then test runs fine. It will be really helpful for me if someone can throw some kight on this. thanks and regards
Re: prepared statement pooling MySQL
Hi Georgi, It's hard to say anything definitive without seeing the prepared statements that are being pooled. We generate slightly different SQL for different databases, and depending on your app it might not lend itself well to pooling with MySQL. Could you enable openjpa SQL tracing to see which statements are being generated? Just add the following property to persistence.xml : property name=openjpa.Log value=SQL=TRACE/ !-- logs to system.err -- or property name=openjpa.Log value=SQL=TRACE,File=/home/mike/sql.log.txt/ !-- logs to /home/mike/sql.log.txt -- When you see the SQL it might explain why pooling doesn't seem to help.. -mike On Mon, Jun 22, 2009 at 6:35 AM, Georgi Naplatanov go...@oles.biz wrote: Hello list I use OpenJPA with Apache DBCP in Java SE environment. My problem is the performance when prepared statement pooling is enabled in DBCP - it is the same as when statement pooling is disabled. My question is - why prepared statement pooling does not increase performance on MySQL ? BTW I made the same test with PostgreSQL and performance is better when prepared statement pooling is enabled. I use MySQL 5.0.51a and OpenJPA 1.2.0 it is the database configuration in my persistence.xml file. property name=openjpa.ConnectionProperties value=driverClassName=com.mysql.jdbc.Driver, url=jdbc:mysql://localhost:3306/cms8?characterEncoding=UTF-8, username=xxx, password=xxx, maxActive=100, maxIdle=100, initialSize=100, poolPreparedStatements=true/ property name=openjpa.ConnectionDriverName value=org.apache.commons.dbcp.BasicDataSource/ Best regards Georgi
Re: Foreign key error if using GenerationType.AUTO or GenerationType.TABLE
Hi, Which version of OpenJPA are you using? OpenJPA does not assume there are any constraints in the database unless you add the @ForeignKey annotation or configure OpenJPA to read constraints from the database. As a result we can sometimes do inserts out of order.. I tried to make this less likely to happen (without changing the underlying assumption about constraints) in OPENJPA-817 [1]. It isn't perfect but it should help for your scenario. [1] http://issues.apache.org/jira/browse/OPENJPA-817 -mike On Mon, Jun 22, 2009 at 6:03 AM, wang yu wangy...@gmail.com wrote: Hello, If I use GenerationType.AUTO or GenerationType.TABLE for PK field and let OpenJPA persist some entities cascade , in some cases, OpenJPA will try to persist child entity before the father entity. How to resolve this issue? I must use GenerationType.AUTO for oracle because it doesn't support GenerationType.IDENTITY naturally. Or do I have a chance to use GenerationType.IDENTITY for Pk fields of oracle database? I have attached the log information in attached file. Thanks! Regards, Yu Wang
Re: Problem with @TableGenerator [OpenJPA 1.2.2]
Hi,
I used your annotation and my test case runs fine.
Given your pkColumnName = table_name, openjpa internally makes this
column name valid for a given database. This code is in ValueTableJDBCSeq:
protected Column addPrimaryKeyColumn(Table table) {
DBDictionary dict = getConfiguration().getDBDictionaryInstance();
Column pkColumn = table.addColumn(dict.getValidColumnName
(getPrimaryKeyColumn(), table));
...
}
Note that the return value from dict.getValidColumnName is table_name0.
From my jdbc log, the table jdo_keygen is created as:
CREATE TABLE jdo_keygen (TABLE_NAME0 VARCHAR(254) NOT NULL, LAST_USED_ID
BIGINT, PRIMARY KEY (TABLE_NAME0))
As a result, there is no problem executing
SELECT LAST_USED_ID FROM jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE
I am using openjpa trunk for this exercise. You might want to turn on jdbc log
to see how create jdo_keygen is created.
Hope this helps.
Fay
- Original Message
From: Michael Simons michael.sim...@optitool.de
To: users@openjpa.apache.org
Sent: Monday, June 22, 2009 6:48:17 AM
Subject: Problem with @TableGenerator [OpenJPA 1.2.2]
Hello,
Here's my annotation:
@TableGenerator(name = pkGenSessionConfig, table = jdo_keygen,
pkColumnName =
table_name, valueColumnName = last_used_id, pkColumnValue =
session_config, allocationSize
= 10)
@Id
@GeneratedValue(strategy=GenerationType.TABLE,
generator=pkGenSessionConfig)
@Column(name=session_config_id, unique=true, nullable=false)
private int id;
And here's the according SQL generated by OpenJPA:
Unknown column 'TABLE_NAME0' in 'where clause' {prepstmnt 32845046 SELECT
LAST_USED_ID FROM
jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE [params=(String) session_config]}
[code=1054,
state=42S22]
Question: Where does OpenJPA take TABLE_NAME0 from while
pkColumnValue=table_name
Kind Regards,
Michael
Re: prepared statement pooling MySQL
Hi Michael here is the log, look at the end of file http://os.oles.biz/opencms/jpa-driver/tmp/jpa-trace.log.tar.gz The application use traditional join syntax property name=openjpa.jdbc.DBDictionary value=JoinSyntax=traditional, SupportsUniqueConstraints=false/ Best regards Georgi Michael Dick wrote: Hi Georgi, It's hard to say anything definitive without seeing the prepared statements that are being pooled. We generate slightly different SQL for different databases, and depending on your app it might not lend itself well to pooling with MySQL. Could you enable openjpa SQL tracing to see which statements are being generated? Just add the following property to persistence.xml : property name=openjpa.Log value=SQL=TRACE/ !-- logs to system.err -- or property name=openjpa.Log value=SQL=TRACE,File=/home/mike/sql.log.txt/ !-- logs to /home/mike/sql.log.txt -- When you see the SQL it might explain why pooling doesn't seem to help.. -mike On Mon, Jun 22, 2009 at 6:35 AM, Georgi Naplatanov go...@oles.biz wrote: Hello list I use OpenJPA with Apache DBCP in Java SE environment. My problem is the performance when prepared statement pooling is enabled in DBCP - it is the same as when statement pooling is disabled. My question is - why prepared statement pooling does not increase performance on MySQL ? BTW I made the same test with PostgreSQL and performance is better when prepared statement pooling is enabled. I use MySQL 5.0.51a and OpenJPA 1.2.0 it is the database configuration in my persistence.xml file. property name=openjpa.ConnectionProperties value=driverClassName=com.mysql.jdbc.Driver, url=jdbc:mysql://localhost:3306/cms8?characterEncoding=UTF-8, username=xxx, password=xxx, maxActive=100, maxIdle=100, initialSize=100, poolPreparedStatements=true/ property name=openjpa.ConnectionDriverName value=org.apache.commons.dbcp.BasicDataSource/ Best regards Georgi
Re: Best practice to avoid duplicates on @Column(unique=true)
David Milosz, Based on the information provided, I do not think Bean Validation would provide a good solution for this problem. Used within the context of JPA, bean validation gets called when various lifecycle events occur; pre-persist, pre-remove, pre-update. In order to create a custom validation constraint, you'd likely need to invoke some database operations (likely some variant of the query Craig suggested). Regarding the use of em query operations inside lifecycle events JPA specification states: spec In general, the lifecycle method of a portable application should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context.[38] A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked. /spec So using database operations, at least within the same persistence context, probably isn't a good idea. Regardless, I think the net result would be that, application-wise, you'd be back in the nearly same situation as present. The exception would still occur on the persist, the main difference would be that the exception would be coming from the validator instead of the failed database operation. -Jeremy On Sat, Jun 20, 2009 at 3:30 AM, Miłosz Tylenda mtyle...@o2.pl wrote: David, Apart from what Craig has suggested, what came to my mind is that there is an ongoing effort to implement JSR-303 Bean Validation in OpenJPA 2.0. Not sure however, whether it is sufficiently implemented yet and it can be used for your purpose. Might be worth checking though. Cheers, Milosz I realise that this is not strickly an OpenJPA problem, rather a more general JPA one, but there are experts here who might know the answer. I have a number of classes which represent tables which have not only an Id field, but also various other fields which are marked as unique. When I persist and then try to flush a new object which has a non-unique value in the object (the user entered bad data) it breaks the transaction and throws an error. All of which is quite understandable. The question is what is the best way to avoid it. Do I have to build the checking into the application, or is there a more generic way which I can use as a validation technique before I try to persist the object. David
Re: Problem with @TableGenerator [OpenJPA 1.2.2]
Hi Fay Wang,
thanks for your reply. As you probably already guessed beacuse of the name
jdo_keygen, we are
porting an application that was based on JDO to JPA. So the table already
exists and we must not
generate it. As the table already exists with a column table_name this name
is valid as a
column name for these databases (we tested with MS SQL Server and MySQL, both
failed for the
same reason).
Can't I tell JPA to take the pkColumnName as is when accessing the database
table?
Can we influence what's assumed a valid column name?
Is there any other opportunity to come around this problem. I thought about
dropping the whole
@GeneratedValue thing and doing the key generating on my own. How do you think
about that idea?
kind regards,
Michael
Fay Wang schrieb:
Hi,
I used your annotation and my test case runs fine.
Given your pkColumnName = table_name, openjpa internally makes this
column name valid for a given database. This code is in ValueTableJDBCSeq:
protected Column addPrimaryKeyColumn(Table table) {
DBDictionary dict = getConfiguration().getDBDictionaryInstance();
Column pkColumn = table.addColumn(dict.getValidColumnName
(getPrimaryKeyColumn(), table));
...
}
Note that the return value from dict.getValidColumnName is table_name0.
From my jdbc log, the table jdo_keygen is created as:
CREATE TABLE jdo_keygen (TABLE_NAME0 VARCHAR(254) NOT NULL, LAST_USED_ID
BIGINT, PRIMARY KEY (TABLE_NAME0))
As a result, there is no problem executing
SELECT LAST_USED_ID FROM jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE
I am using openjpa trunk for this exercise. You might want to turn on jdbc
log to see how create jdo_keygen is created.
Hope this helps.
Fay
- Original Message
From: Michael Simons michael.sim...@optitool.de
To: users@openjpa.apache.org
Sent: Monday, June 22, 2009 6:48:17 AM
Subject: Problem with @TableGenerator [OpenJPA 1.2.2]
Hello,
Here's my annotation:
@TableGenerator(name = pkGenSessionConfig, table = jdo_keygen,
pkColumnName =
table_name, valueColumnName = last_used_id, pkColumnValue =
session_config, allocationSize
= 10)
@Id
@GeneratedValue(strategy=GenerationType.TABLE,
generator=pkGenSessionConfig)
@Column(name=session_config_id, unique=true, nullable=false)
private int id;
And here's the according SQL generated by OpenJPA:
Unknown column 'TABLE_NAME0' in 'where clause' {prepstmnt 32845046 SELECT
LAST_USED_ID FROM
jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE [params=(String) session_config]}
[code=1054,
state=42S22]
Question: Where does OpenJPA take TABLE_NAME0 from while
pkColumnValue=table_name
Kind Regards,
Michael
Re: Foreign key error if using GenerationType.AUTO or GenerationType.TABLE
Hi! Also, you will find child father ideas in thread [1]. The FAQ [2] mentions it too. As for IDENTITY with Oracle, you could try the emulation feature [3]. It emulates auto-increment columns by using triggers. Regards, Milosz [1] http://n2.nabble.com/Inconsistent-behaviour-with-Bi-directional-One-to-Many-Mapping.-tp2570464p2570464.html [2] http://openjpa.apache.org/faq.html [3] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_dbsetup_dbsupport_oracle Hi, Which version of OpenJPA are you using? OpenJPA does not assume there are any constraints in the database unless you add the @ForeignKey annotation or configure OpenJPA to read constraints from the database. As a result we can sometimes do inserts out of order.. I tried to make this less likely to happen (without changing the underlying assumption about constraints) in OPENJPA-817 [1]. It isn't perfect but it should help for your scenario. [1] http://issues.apache.org/jira/browse/OPENJPA-817 -mike On Mon, Jun 22, 2009 at 6:03 AM, wang yu wrote: Hello, If I use GenerationType.AUTO or GenerationType.TABLE for PK field and let OpenJPA persist some entities cascade , in some cases, OpenJPA will try to persist child entity before the father entity. How to resolve this issue? I must use GenerationType.AUTO for oracle because it doesn't support GenerationType.IDENTITY naturally. Or do I have a chance to use GenerationType.IDENTITY for Pk fields of oracle database? I have attached the log information in attached file. Thanks! Regards, Yu Wang
Re: openjpa.LockManager
2009/6/10 Daryl Stultz da...@6degrees.com Yup, I forgot the @ForeignKey annotation. I have added it and reverted to my cascade/not deferrable setting and it seems to be working. Thanks! Well, the @ForeignKey did take care of the ordering of the SQL, but I deployed it to a test server and it failed the original way. I said above that I reverted to cascade/not deferrable, I did but on the wrong database instance. So I ultimately had to define the foreign key in the DB as cascade no action deferrable initialy deferred (PostgreSQL) to get it to work. I have to say it's rather confusing to have an optimistic locking error thrown when the lock manager is set to none. Not sure if there is some other feedback that can be given in a case like this. -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com
Re: Best practice to avoid duplicates on @Column(unique=true)
Hi Milosz, Great observation questions. The sentence you refer to means that you can directly invoke a JSR-303 validator at any time from the application. ex: javax.validation.ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); javax.validation.Validator validator = factory.getValidator(); EntityA a = em.find(EntityA.class, IdOfA); SetConstraintViolationEntityA cvs = validator.validate(a); I've only briefly read over how one may create and tie a constraint validator implementation class to a custom constraint, but I don't see an immediate way that the constraint validator could get access (outside of some static helper method) to an em during the validation process. That said, I did not read anything in the specs (but, I could easily have missed something) that would prevent the constraint validator from accessing an em during application driven validation... so it could potentially be used during that process. Care would need to be taken not to cause unintended side-effects (locks, loading, tx commit/rollback, etc.). One more thing to keep in mind, application driven validation also requires a JPA traversable resolver to prevent from validating unloaded or related entities. OpenJPA does not provide a resolver, but the plan is to provide one in a future iteration of 2.0. Until that is available, validating of unloaded and related entities (if tagged with @Valid) will occur. BTW, This scenario will make a great set of test cases. :-) -Jeremy On Mon, Jun 22, 2009 at 12:59 PM, Miłosz Tylenda mtyle...@o2.pl wrote: Jeremy, Thanks for the explanation. Maybe you could also explain this sentence from the spec: Validation can also be achieved by the application calling the validate method of a validator instance upon an instance of a managed class, as described in the Bean Validation specification [8] Does it mean we can call validate at whatever time in the persistence context? Can we access entity manager then? Greetings, Milosz David Milosz, Based on the information provided, I do not think Bean Validation would provide a good solution for this problem. Used within the context of JPA, bean validation gets called when various lifecycle events occur; pre-persist, pre-remove, pre-update. In order to create a custom validation constraint, you'd likely need to invoke some database operations (likely some variant of the query Craig suggested). Regarding the use of em query operations inside lifecycle events JPA specification states: In general, the lifecycle method of a portable application should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context.[38] A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked. So using database operations, at least within the same persistence context, probably isn't a good idea. Regardless, I think the net result would be that, application-wise, you'd be back in the nearly same situation as present. The exception would still occur on the persist, the main difference would be that the exception would be coming from the validator instead of the failed database operation. -Jeremy On Sat, Jun 20, 2009 at 3:30 AM, Miłosz Tylenda wrote: David, Apart from what Craig has suggested, what came to my mind is that there is an ongoing effort to implement JSR-303 Bean Validation in OpenJPA 2.0. Not sure however, whether it is sufficiently implemented yet and it can be used for your purpose. Might be worth checking though. Cheers, Milosz I realise that this is not strickly an OpenJPA problem, rather a more general JPA one, but there are experts here who might know the answer. I have a number of classes which represent tables which have not only an Id field, but also various other fields which are marked as unique. When I persist and then try to flush a new object which has a non-unique value in the object (the user entered bad data) it breaks the transaction and throws an error. All of which is quite understandable. The question is what is the best way to avoid it. Do I have to build the checking into the application, or is there a more generic way which I can use as a validation technique before I try to persist the object. David
Re: Problem with @TableGenerator [OpenJPA 1.2.2]
As a workaround so that you can proceed, could you alter your jdo_keygen table
by changing the column table_name to table_name0, meanwhile you might want to
open a jira issue for this problem.
Regards,
Fay
- Original Message
From: Michael Simons michael.sim...@optitool.de
To: users@openjpa.apache.org
Sent: Monday, June 22, 2009 9:58:33 AM
Subject: Re: Problem with @TableGenerator [OpenJPA 1.2.2]
Hi Fay Wang,
thanks for your reply. As you probably already guessed beacuse of the name
jdo_keygen, we are
porting an application that was based on JDO to JPA. So the table already
exists and we must not
generate it. As the table already exists with a column table_name this name
is valid as a
column name for these databases (we tested with MS SQL Server and MySQL, both
failed for the
same reason).
Can't I tell JPA to take the pkColumnName as is when accessing the database
table?
Can we influence what's assumed a valid column name?
Is there any other opportunity to come around this problem. I thought about
dropping the whole
@GeneratedValue thing and doing the key generating on my own. How do you think
about that idea?
kind regards,
Michael
Fay Wang schrieb:
Hi,
I used your annotation and my test case runs fine.
Given your pkColumnName = table_name, openjpa internally makes this
column name valid for a given database. This code is in ValueTableJDBCSeq:
protected Column addPrimaryKeyColumn(Table table) {
DBDictionary dict = getConfiguration().getDBDictionaryInstance();
Column pkColumn = table.addColumn(dict.getValidColumnName
(getPrimaryKeyColumn(), table));
...
}
Note that the return value from dict.getValidColumnName is table_name0.
From my jdbc log, the table jdo_keygen is created as:
CREATE TABLE jdo_keygen (TABLE_NAME0 VARCHAR(254) NOT NULL, LAST_USED_ID
BIGINT, PRIMARY KEY (TABLE_NAME0))
As a result, there is no problem executing
SELECT LAST_USED_ID FROM jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE
I am using openjpa trunk for this exercise. You might want to turn on jdbc
log to see how create jdo_keygen is created.
Hope this helps.
Fay
- Original Message
From: Michael Simons michael.sim...@optitool.de
To: users@openjpa.apache.org
Sent: Monday, June 22, 2009 6:48:17 AM
Subject: Problem with @TableGenerator [OpenJPA 1.2.2]
Hello,
Here's my annotation:
@TableGenerator(name = pkGenSessionConfig, table = jdo_keygen,
pkColumnName =
table_name, valueColumnName = last_used_id, pkColumnValue =
session_config, allocationSize
= 10)
@Id
@GeneratedValue(strategy=GenerationType.TABLE,
generator=pkGenSessionConfig)
@Column(name=session_config_id, unique=true, nullable=false)
private int id;
And here's the according SQL generated by OpenJPA:
Unknown column 'TABLE_NAME0' in 'where clause' {prepstmnt 32845046 SELECT
LAST_USED_ID FROM
jdo_keygen WHERE TABLE_NAME0 = ? FOR UPDATE [params=(String) session_config]}
[code=1054,
state=42S22]
Question: Where does OpenJPA take TABLE_NAME0 from while
pkColumnValue=table_name
Kind Regards,
Michael
Re: Foreign key error if using GenerationType.AUTO or GenerationType.TABLE
hello mike, Thank you for your prompt and detailed response. I use OpenJPA 1.2.1. I have added foolowing into persistence.xml property name=openjpa.jdbc.SynchronizeMappings value=buildSchema(ForeignKeys=true) / property name=openjpa.jdbc.UpdateManager value=operation-order/ and @ForeignKey(enabled=true) for all foreign key fields according to your suggestion. For GenerationType.AUTO, some insert operation still failed. My case is little bit complicated, it has very deep entity hierarchy and mixed with insert,update and delete operations in one deep entity tree. I'm afraid the root cause is UpdateManager of OpenJPA is not so perfect for complicated case. Maybe I should try to persist entities without cascade? Regards, Yu Wang On Tue, Jun 23, 2009 at 2:17 AM, Miłosz Tylendamtyle...@o2.pl wrote: Hi! Also, you will find child father ideas in thread [1]. The FAQ [2] mentions it too. As for IDENTITY with Oracle, you could try the emulation feature [3]. It emulates auto-increment columns by using triggers. Regards, Milosz [1] http://n2.nabble.com/Inconsistent-behaviour-with-Bi-directional-One-to-Many-Mapping.-tp2570464p2570464.html [2] http://openjpa.apache.org/faq.html [3] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_dbsetup_dbsupport_oracle Hi, Which version of OpenJPA are you using? OpenJPA does not assume there are any constraints in the database unless you add the @ForeignKey annotation or configure OpenJPA to read constraints from the database. As a result we can sometimes do inserts out of order.. I tried to make this less likely to happen (without changing the underlying assumption about constraints) in OPENJPA-817 [1]. It isn't perfect but it should help for your scenario. [1] http://issues.apache.org/jira/browse/OPENJPA-817 -mike On Mon, Jun 22, 2009 at 6:03 AM, wang yu wrote: Hello, If I use GenerationType.AUTO or GenerationType.TABLE for PK field and let OpenJPA persist some entities cascade , in some cases, OpenJPA will try to persist child entity before the father entity. How to resolve this issue? I must use GenerationType.AUTO for oracle because it doesn't support GenerationType.IDENTITY naturally. Or do I have a chance to use GenerationType.IDENTITY for Pk fields of oracle database? I have attached the log information in attached file. Thanks! Regards, Yu Wang
