In fact, I'm just thinking the point 2 is not in any issue, I'm not sure it 
should be but I don't see why a unique constraint would make sense on primary 
key, so an error should be raised in that case.

On Dec 13, 2009, at 21:38 , Jean-Baptiste BRIAUD -- Novlog wrote:

> Exactly the issues !
> I'm using a 1.2.2. snapshot.
> 
> Unfortunately, this code is for production, so, no trunk !
> 
> Thanks for the help.
> 
> On Dec 13, 2009, at 09:41 , Miłosz Tylenda wrote:
> 
>> Hi Jean-Baptiste,
>> 
>> I can see two problems in the case you have described:
>> 
>> 1. Unique constraints are being named by OpenJPA as "UNQ_" instead of 
>> something like "UNQ_TABLE_COLUMN".
>> 
>> 2. For most databases it is redundant or even incorrect for OpenJPA to 
>> create unique constraints on primary keys.
>> 
>> What OpenJPA version are you using? Unique constraint handling has been 
>> reworked in the trunk (future 2.0.0) and 1.3.x branch but there is still 
>> room for improvement. You are experiencing same or similar behaviour as 
>> described in OPENJPA-756 and OPENJPA-1047 [1].
>> 
>> Greetings,
>> Milosz
>> 
>> [1] http://issues.apache.org/jira/browse/OPENJPA-756
>> http://issues.apache.org/jira/browse/OPENJPA-1047
>> 
>>> I found a workaround or a solution, depending if the behavior is a bug or 
>>> not.
>>> 
>>> This constraint was due to the following declaration in an abstract class 
>>> all persistant classes inherits from :
>>>   @Id
>>>   @GeneratedValue(strategy = GenerationType.IDENTITY)
>>>   @Column(nullable = false, unique = true)
>>>   private Long id;
>>> 
>>> Is it usefull to declare unique the primary key ? I guess it is at least 
>>> redundant.
>>> I removed it and it works fine :
>>>   @Id
>>>   @GeneratedValue(strategy = GenerationType.IDENTITY)
>>>   @Column(nullable = false)
>>>   private Long id;
>>> 
>>> 
>>> One question is still there for OpenJPA : should the enhance process detect 
>>> that redundancy ? Should it fails on error for that ?
>>> 
>>> If yes, than it is a bug, if no, then it is a workaround :-)
>>> 
>>> On Dec 11, 2009, at 18:22 , Jean-Baptiste BRIAUD -- Novlog wrote:
>>> 
>>>> Hi the list,
>>>> 
>>>> On my DEV machine I'm using MySQL, I use the MappingTool Ant task and its 
>>>> all OK.
>>>> I produce the ddl sql file (for human reading) and also directly "inject" 
>>>> the schema using the MappingTool to the database (not using the generated 
>>>> sql file).
>>>> 
>>>> On PROD, I have to deal with SQLServer. I amended the ant script in order 
>>>> to connect using a URL specific to SQLServer. I rely on JTDS open source 
>>>> SQLServer JDBC driver.
>>>> JDBC connection is fine, but I got an error on the SQL, I have to modify 
>>>> it by hand to make it work.
>>>> 
>>>> I didn't try to specify a "dialect" in the ant script, should I ?
>>>> If yes, how ?
>>>> 
>>>> The error is on the constraint that are all named UNQ_ and it sound like a 
>>>> problem for SQLServer.
>>>> CREATE TABLE A (id BIGINT NOT NULL AUTO_INCREMENT<...>, PRIMARY KEY (id), 
>>>> UNIQUE UNQ_ (id));
>>>> CREATE TABLE B (id BIGINT NOT NULL AUTO_INCREMENT<...>, PRIMARY KEY (id), 
>>>> UNIQUE UNQ_ (id));
>>>> 
>>>> If I correct the sql by hand like the following, it works :
>>>> CREATE TABLE A (id BIGINT NOT NULL AUTO_INCREMENT<...>, PRIMARY KEY (id), 
>>>> UNIQUE UNQ_1 (id));
>>>> CREATE TABLE B (id BIGINT NOT NULL AUTO_INCREMENT<...>, PRIMARY KEY (id), 
>>>> UNIQUE UNQ_2 (id));
>>>> 
>>>> I can't do it by hand for the real code for a lot of reason, I have to 
>>>> rely on MappingTool.
>>>> 
>>>> Any ideas ?
>>> 
>>> 
>> 
> 
> 

Reply via email to