Re: Cayenne 1.2 + PostgreSQL

From: Kevin Menard (kmenar..ervprise.com)
Date: Mon Dec 12 2005 - 21:12:12 EST

  • Next message: Cris Daniluk: "Re: Cayenne 1.2 + PostgreSQL"

    On 12/12/05 6:25 PM, "Cris Daniluk" <cris.danilu..mail.com> wrote:

    > Well, you need to keep in mind that most users won't do this. I
    > *personally* prefer to keep the modeler simple. If the average user
    > shouldn't need to do something, leave it to the API. So I wouldn't
    > bitch about a solution that involves the modeler, but I do think that
    > the DbAdapter should have a default that can only be overridden via
    > some type of code.

    Well, the proposed solution would actually let the PkGenerator be specified
    in XML. Since the modeler wraps around that, it seemed natural for the
    Modeler to have some way of modifying it. If it was decided to keep the
    modeler simpler, those wanting to override the default PkGenerator could do
    so easily.
     
    > You mentioned before that a user may want to vary PkGeneration from
    > object to object, for compatibility, etc. Maybe the right thing is to
    > add DataObject.getAlternatePkGenerator()... then you could have two
    > base objects in your code base... one for objects that use the default
    > pk generation (and therefore do not override the method) and one for
    > objects that use the auto-pk support..

    I was actually talking adapter to adapter. Michael was the one that
    suggested per entity. I do think he may be on to something, but that would
    work in a fundamentally different manner than what I was proposing. I was
    talking about exposing, what is for all intents and purposes, an existing
    property. What both of you are now suggesting is moving it away from the db
    adapter altogether (or, at least the ability to override it).

    While I like the general idea of what you're proposing, I'm a bit lost as to
    where the default pk generation strategy will come from. As it stands now,
    data objects are shielded from rdbms-specific things. The various pk
    generators are actually quite rdbms-bound. This may not be a problem if
    there was a default generator for all sequence-based pks or what have you,
    as Andrus suggested. Or, are you simply suggesting the db adapter checks
    the return value of getAlternatePkGenerator() and if it's null, use its own
    default pk generator?

    -- 
    Kevin
    



    This archive was generated by hypermail 2.0.0 : Mon Dec 12 2005 - 21:12:21 EST