You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Tore Halset <ha...@pvv.ntnu.no> on 2007/12/19 08:39:30 UTC
DbRelationship and FK_NAME
Hello.
I want to pick up FK_NAME in DbLoader and store it temporarily in the
DbRelationship. This is for the merging of foreign keys. See CAY-937.
Should I add fkName as a transient attribute to DbRelationship or
create a subclass of DbRelationship called something like
DbRelationshipWithFkName?
Regards,
- Tore.
Re: DbRelationship and FK_NAME
Posted by Andrus Adamchik <an...@objectstyle.org>.
Sorry... I completely forgot about this one. I actually did some
research on that before in relation to CAY-116, and even wrote some
code to drop constraints using FK_NAME (although it does not work for
all DB's):
https://svn.apache.org/repos/asf/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/unit/AccessStackAdapter.java
Andrus
On Dec 19, 2007, at 3:20 PM, Tore Halset wrote:
> On Dec 19, 2007, at 12:36 , Andrus Adamchik wrote:
>
>> Hmm... I thought FK_NAME was a column name of the FK?
>
> Example from cayenne junit db in PostgreSQL:
>
> cayenne=> \d painting
> Table "public.painting"
> Column | Type | Modifiers
> ----------------------+------------------------+-----------
> artist_id | integer |
> estimated_price | numeric(10,2) |
> gallery_id | integer |
> painting_description | character varying(255) |
> painting_id | integer | not null
> painting_title | character varying(255) | not null
> Indexes:
> "painting_pkey" PRIMARY KEY, btree (painting_id)
> Foreign-key constraints:
> "painting_artist_id_fkey" FOREIGN KEY (artist_id) REFERENCES
> artist(artist_id)
> "painting_gallery_id_fkey" FOREIGN KEY (gallery_id) REFERENCES
> gallery(gallery_id)
>
> Here "painting_artist_id_fkey" and "painting_gallery_id_fkey" are
> FK_NAMEs. Those are needed only when you want to drop the foreign key.
>
> Regards,
> - Tore.
>
>
Re: DbRelationship and FK_NAME
Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Dec 19, 2007, at 12:36 , Andrus Adamchik wrote:
> Hmm... I thought FK_NAME was a column name of the FK?
Example from cayenne junit db in PostgreSQL:
cayenne=> \d painting
Table "public.painting"
Column | Type | Modifiers
----------------------+------------------------+-----------
artist_id | integer |
estimated_price | numeric(10,2) |
gallery_id | integer |
painting_description | character varying(255) |
painting_id | integer | not null
painting_title | character varying(255) | not null
Indexes:
"painting_pkey" PRIMARY KEY, btree (painting_id)
Foreign-key constraints:
"painting_artist_id_fkey" FOREIGN KEY (artist_id) REFERENCES
artist(artist_id)
"painting_gallery_id_fkey" FOREIGN KEY (gallery_id) REFERENCES
gallery(gallery_id)
Here "painting_artist_id_fkey" and "painting_gallery_id_fkey" are
FK_NAMEs. Those are needed only when you want to drop the foreign key.
Regards,
- Tore.
Re: DbRelationship and FK_NAME
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hmm... I thought FK_NAME was a column name of the FK?
Andrus
On Dec 19, 2007, at 1:23 PM, Tore Halset wrote:
> On Dec 19, 2007, at 12:02 , Andrus Adamchik wrote:
>
>> Oh wait! FK_NAME is also available from a join right? (I was
>> thinking about "FK constraint name" when I sent my last email).
>
> Currently cayenne does not know the FK_NAME as it is not needed. It
> is only needed to drop the FK by the merger. And, this name is
> typically generated by the db (if you do not specify it upon create).
>
>> Yeah, let's probably use a non-public subclass if you need to store
>> extra info during a DbLoader run.
>
> Yes, I will create a subclass. Must probably be public as the
> DbLoader and the DbMerger exist in different packages or what?
>
> Regards,
> - Tore.
>
>
Re: DbRelationship and FK_NAME
Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Dec 19, 2007, at 12:02 , Andrus Adamchik wrote:
> Oh wait! FK_NAME is also available from a join right? (I was
> thinking about "FK constraint name" when I sent my last email).
Currently cayenne does not know the FK_NAME as it is not needed. It is
only needed to drop the FK by the merger. And, this name is typically
generated by the db (if you do not specify it upon create).
> Yeah, let's probably use a non-public subclass if you need to store
> extra info during a DbLoader run.
Yes, I will create a subclass. Must probably be public as the DbLoader
and the DbMerger exist in different packages or what?
Regards,
- Tore.
Re: DbRelationship and FK_NAME
Posted by Andrus Adamchik <an...@objectstyle.org>.
Oh wait! FK_NAME is also available from a join right? (I was thinking
about "FK constraint name" when I sent my last email).
Yeah, let's probably use a non-public subclass if you need to store
extra info during a DbLoader run.
Andrus
On Dec 19, 2007, at 12:59 PM, Andrus Adamchik wrote:
> I am +1 on adding this extra field to DbRelationship. This can be a
> useful piece of metadata down the road.
>
> Andrus
>
>
> On Dec 19, 2007, at 9:39 AM, Tore Halset wrote:
>> Hello.
>>
>> I want to pick up FK_NAME in DbLoader and store it temporarily in
>> the DbRelationship. This is for the merging of foreign keys. See
>> CAY-937.
>>
>> Should I add fkName as a transient attribute to DbRelationship or
>> create a subclass of DbRelationship called something like
>> DbRelationshipWithFkName?
>>
>> Regards,
>> - Tore.
>>
>
>
Re: DbRelationship and FK_NAME
Posted by Andrus Adamchik <an...@objectstyle.org>.
I am +1 on adding this extra field to DbRelationship. This can be a
useful piece of metadata down the road.
Andrus
On Dec 19, 2007, at 9:39 AM, Tore Halset wrote:
> Hello.
>
> I want to pick up FK_NAME in DbLoader and store it temporarily in
> the DbRelationship. This is for the merging of foreign keys. See
> CAY-937.
>
> Should I add fkName as a transient attribute to DbRelationship or
> create a subclass of DbRelationship called something like
> DbRelationshipWithFkName?
>
> Regards,
> - Tore.
>