persistence@glassfish.java.net

Re: Unwanted unique constraint on join table

From: Tom Ware <tom.ware_at_oracle.com>
Date: Tue, 07 Nov 2006 16:09:58 -0500

Hi Greg,

  You should be able to use TopLink essentials to generate some files
that will contain the DDL statements you want and then edit those
files. I realize that is not quite as easy as having the DDL
automatically created on the database, but it could help.

  If you want to give it a try, take a look at the schema generation
extensions in the following document:

http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#Java2DBSchemaGen

- set |toplink.ddl-generation to either ||create-tables or||
drop-and-create-tables|
- set |toplink.create-ddl-jdbc-file-name to the name and location of the
file that should contain the create statements
- set ||toplink.drop-ddl-jdbc-file-name to the name and location of the
file that should contain the drop statements (if you are using the
||drop-and-create-tables| option above|)
- set ||toplink.ddl-generation.output-mode to ||sql-script

This should produce some files that can fairly easily be edited to
produce some files you can use to build your DDL. The are ".jdbc"
files, so in order to make the into runnable sql files, you will likely
have to add some line terminators. In addition, you should be able to
make any edits you choose.

Note: Currently due to glassfish issue 1171, if you are running in SE,
we will also attempt to create the tables on the database, but that
should not interfere with the correctness of the files.

-Tom



|Marina Vatkina wrote:

>Hi Greg,
>
>I suggest to file a bug and attach a simple test case ;).
>
>If you have a legacy system, can you use its DDL to create your test
>environment?
>
>Is your application a JavaEE app? The actual solution will depend on the mode
>in which you use TopLink Essentials DDL generation. But in any case the idea
>would be to take the generated .jdbc file, modify and load it yourself, then
>do not use auto DDL generation.
>
>Does it make sense?
>
>thanks,
>-marina
>
>Greg Ederer wrote:
>
>
>>Hi Marina,
>>
>>This does create a table with the correct structure; however, I lose
>>control over the name of the table, and the column names. I would like
>>these names to match those in a legacy system. I just tried it with
>>@JoinTable(name="user_role"), and I got the correct structure and table
>>name, but the column names do not match those in my legacy table.
>>
>>Any other suggestions?
>>
>>Thanks for the help.
>>
>>Greg
>>
>>Marina Vatkina wrote:
>>
>>
>>
>>>Hi Greg,
>>>
>>>Does it work if you remove @JoinTable annotation? If you use the DDL
>>>generation
>>>feature, the provider will generate a join table for you automatically.
>>>
>>>thanks,
>>>-marina
>>>
>>>Greg Ederer wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I have a ManyToMany relationship between two classes, annotated like
>>>>so at the owning end:
>>>>
>>>> @ManyToMany
>>>> @JoinTable(name = "user_role", joinColumns =
>>>> {_at_JoinColumn(name = "username", referencedColumnName = "username")},
>>>> inverseJoinColumns = {_at_JoinColumn(name = "role_name",
>>>>referencedColumnName = "name")})
>>>> private List<Role> roles = new ArrayList<Role>();
>>>>
>>>>At the other end:
>>>>
>>>> @ManyToMany(mappedBy="roles")
>>>> private List<AppUser> appUsers = new ArrayList<AppUser>();
>>>>
>>>>This produces the following join table (PostgreSQL):
>>>>
>>>>CREATE TABLE user_role
>>>>(
>>>> role_name varchar(255) NOT NULL,
>>>> username varchar(255) NOT NULL,
>>>> CONSTRAINT user_role_pkey PRIMARY KEY (role_name, username),
>>>> CONSTRAINT fk_user_role_role_name FOREIGN KEY (role_name)
>>>> REFERENCES "role" (name) MATCH SIMPLE
>>>> ON UPDATE NO ACTION ON DELETE NO ACTION,
>>>> CONSTRAINT fk_user_role_username FOREIGN KEY (username)
>>>> REFERENCES app_user (username) MATCH SIMPLE
>>>> ON UPDATE NO ACTION ON DELETE NO ACTION,
>>>> CONSTRAINT user_role_username_key UNIQUE (username)
>>>>)
>>>>
>>>>The user_role_username_key is unwanted. How can I prevent it from
>>>>being generated?
>>>>
>>>>Thanks!
>>>>
>>>>Greg
>>>>--
>>>>
>>>>| E R G O N O S I S
>>>>| Greg Ederer
>>>>| Lead Developer
>>>>| greg_at_ergonosis.com
>>>>| 360.379.1157
>>>>| | OpenDocument - OK <http://openoffice.org/>
>>>>|
>>>>
>>>>
>>>>
>>--
>>
>>| E R G O N O S I S
>>| Greg Ederer
>>| Lead Developer
>>| greg_at_ergonosis.com
>>| 360.379.1157
>>|
>>| OpenDocument - OK <http://openoffice.org/>
>>|
>>
>>
>>