Re: Using a custom PK Table

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using a custom PK Table

Andrus Adamchik
To add to what Mike wrote, JdbcAdapter (superclass of all standard
DbAdapters) has a method "setPkGenerator", so you can provide a custom
PkGenerator for any existing adapter.

Andrus

> Albert Jagnow <[hidden email]> wrote:
>> I am working on a web version of an application that uses the same data
>> as a legacy RPG application.  The PK values for the tables come from a
>> table with columns for table name and last used PK value.  The legacy
>> RPG application is adding records at the same time I am adding records
>> from the web application.  In my testing I have run into some problems
>> with conflicting PK values.  I was using DataObjectUtils.objectForPK
>> passing in the table name to obtain the next PK value for the table, but
>> this appears to not always grab the most current data from the table.
>> What is the best method to quickly get and update the next PK value?
>> Also does cayenne have the ability to use a PK delegate like in
>> WebObjects, that will call my custom PK generation method for a given
>> entity automatically when the data is to be written to the database?
>
> If you take a look at DbAdaptor, you can create a subclass of your adaptor
> and provide an alternate generator.
> It's pretty simple to do.   The standard auto pk generation is very
> similar
> to both webobjects and to the RPG code you've describe, so it'd probably
> just be a matter of providing a different table and column nameset.
>
> -Mike
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Using a custom PK Table

Albert Jagnow
Thanks for the comments.  By coping and customizing some of the code in
the JdbcPKGenerator, I am able to manually call a custom pk generator to
get a good pk value.  The tricky part in getting Cayenne to generate the
pk, is in my case most of the tables I am using for my web application
are independent of the legacy tables, and for my new web tables I am
using sequences in DB2 generated by the adaptor for the primary key.  I
think I want to keep doing that. The only tables where it is an issue
are the two tables I am sharing with the legacy application. What I
would like to do is change the PK generation method for just those two
entities, and leave the other entities to use the adaptor default.  Is
that possible? If not I think it will work OK how I have it now.

--Albert

-----Original Message-----
From: Andrus Adamchik [mailto:[hidden email]]
Sent: Tuesday, July 26, 2005 3:12 PM
To: [hidden email]
Subject: Re: Using a custom PK Table

To add to what Mike wrote, JdbcAdapter (superclass of all standard
DbAdapters) has a method "setPkGenerator", so you can provide a custom
PkGenerator for any existing adapter.

Andrus

> Albert Jagnow <[hidden email]> wrote:
>> I am working on a web version of an application that uses the same
data
>> as a legacy RPG application.  The PK values for the tables come from
a
>> table with columns for table name and last used PK value.  The legacy
>> RPG application is adding records at the same time I am adding
records
>> from the web application.  In my testing I have run into some
problems
>> with conflicting PK values.  I was using DataObjectUtils.objectForPK
>> passing in the table name to obtain the next PK value for the table,
but
>> this appears to not always grab the most current data from the table.
>> What is the best method to quickly get and update the next PK value?
>> Also does cayenne have the ability to use a PK delegate like in
>> WebObjects, that will call my custom PK generation method for a given
>> entity automatically when the data is to be written to the database?
>
> If you take a look at DbAdaptor, you can create a subclass of your
adaptor
> and provide an alternate generator.
> It's pretty simple to do.   The standard auto pk generation is very
> similar
> to both webobjects and to the RPG code you've describe, so it'd
probably
> just be a matter of providing a different table and column nameset.
>
> -Mike
>



Loading...