Re: Error trying to commit

From: Dirk Olmes (dirk.olme..mx.de)
Date: Mon Jun 02 2003 - 09:45:46 EDT

  • Next message: Andrus Adamchik: "Re: Error trying to commit"

    > BTW, just added support for custom sequence names to the Modeler. This
    > is available in the nightly build:
    >
    > http://objectstyle.org/downloads/cayenne/nightly/2003-5-31/
    >
    > Note that only Oracle adapter takes these settings into account.

    I wanted to jump into implementing custom sequences for PostgreSQL as well
    this morning so I
    checked out a fresh version and started work. First I was surprised that
    there was no
    PostgreSQL Sequence PK generator in the CVS as I have worked on such a beast
    in the past.
    Then I remembered that I must have forgotten to provide Holger with a patch
    so it never made
    it into cayenne CVS. I'll check my cayenne version on the machine at home
    when I am back home.

    While I was working on the PostgreSQL Sequence Key generator I thought of a
    new structure for
    the PK generation mechanism. I'd like to get rid of DBKeyGenerator class
    and put that
    functionality into an extended PKGenerator hierarchy.

    Currently, DBKeyGenerator only exists to hold the sequence name that will be
    used when
    creating a new PK with Oracle. Since there will be more adaptors being able
    to generate PKs
    from sequences (Postgres, DB2) there will be need to factor this out sooner
    or later anyway.

    Here's what I'd like to propose:

    1) DBEntity holds a reference to the PKGenerator. Unlike now, this should
    provide a more
    consistent behaviour: asking a DBEntity for a PKGenerator should never
    return null. If there's
    no PKGenerator configured for a specific entity it returns the PKGenerator
    for the adaptor.
    So you'll never have to jump around in hoops just to generate a PK and gets
    rid of long
    if-then-else cascades to determine the correct PKGenerator.

    2) Refactor the existing classes for Primary Key Generation like:

    [PKGenerator <<Interface>>]-------------[AbstractPkGenerator]
                                                     |
                                           ----------------------
                                           | |
                                     [TablePkGenerator] [SequencePkGenerator]
                                           |
                               [OracleTablePkGenerator] etc.
                               
                               
    3) Thus, PK generation will become more flexible: You can configure a custom
    sequence for one
    DBEntity, Table-based PK generation for another, even an in-memory PK
    generator generating
    UUID primary keys would be possible.

    4) Refactore Modeler to provide a PopUp for the PK generation strategy
    chosen for the
    DBEntity, if nothing is chosen we'll fall back to the strategy that comes
    with the adaptor.

    This won't be an easy change, though and I guess it won't happen in the
    current beta phase.
    I'll volunteer to make the appropriate changes if everyone agrees.

    What do you all think?

    -dirk

    -- 
    +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
    Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
    



    This archive was generated by hypermail 2.0.0 : Mon Jun 02 2003 - 09:44:38 EDT