Re: question about key generation

From: Mike Kienenberger (mkienen..laska.net)
Date: Thu Feb 24 2005 - 22:40:32 EST

  • Next message: tnaki..ofthome.net: "cayenne.xml not found - completely at a loss here..."

    Roman D <dostic..mail.com> wrote:
    > What is the best practice to have database structure which is completely
    > free of DB-specific features (e.g. not using mysql auto_increment or
    > Oracle sequence) and is it possible without having Cayenne-specific
    > "AUTO_PK_SUPPORT" tables?

    Andrus has already answered this for the most part, but as far as I know,
    using "AUTO_PK_SUPPORT" tables are the only database-independent and
    application-independent way to support primary key generation.

    WebObjects uses the same technique (different table name) and, looking at
    hibernate hilo docs, so does Hibernate. It's basically a database table
    that contains table name, next assignable primary key value, and optionally
    the primary key field name. Some get a bit more fancy and thrown in some
    other options like increment-by values so you can reserve the next N primary
    key values rather than just one.

    If you're going to access multiple database vendors, but only through
    cayenne, use native pk generation (which will vary for each db).
    If you're going to access one database vendor with cayenne and other apps,
    use the native pk generation (providing each app supports it).

    If you're going to access multiple database vendors with multiple app
    frameworks, use some kind of pk support table. And chances are, it'll be
    easier to adapt Cayenne to use the "other apps" table than to make the other
    app use Cayennes (just clone the auto-pk-support class and change the table
    name and fields). The downside of a pk support table is it generally does
    not support clustering and other fun multi-instance database configurations.
     At least that's true for OpenBase.

    -Mike



    This archive was generated by hypermail 2.0.0 : Thu Feb 24 2005 - 22:39:50 EST