Re: Cayenne 1.2 + PostgreSQL

From: Cris Daniluk (cris.danilu..mail.com)
Date: Mon Dec 12 2005 - 18:25:02 EST

  • Next message: Kevin Menard: "Re: Cayenne 1.2 + PostgreSQL"

    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.

    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..

    Just another thought.

    On 12/12/05, Kevin Menard <kmenar..ervprise.com> wrote:
    > If that's the approach we want to take, then that's fine. It'll certainly
    > work (well, not in Michael's case), but tightly couples the DbAdapter and
    > PkGenerator. Conceptually, I guess they already are coupled. It just seems
    > a bit odd to me to subclass, for example, the Postgres DB adapter, only to
    > change what PkGenerator it returns. Although I agree, it is the easiest
    > solution to the problem.
    >
    > --
    > Kevin
    >
    >
    > On 12/10/05 7:57 AM, "Andrus Adamchik" <andru..bjectstyle.org> wrote:
    >
    > >> Make more sense now? Or am I trying to fix a non-issue?
    > >
    > > The issue is that users need the ability to choose a PK generator
    > > algorithm, right? There is more than one way to address it. Cayenne
    > > already supports the simplest one - provide a custom DbAdapter that
    > > installs specific generator on load. I am not convinced that we need
    > > anything more complex than that, further complicating Modeler
    > > configuration.
    > >
    > > We can make things easier by providing adapter-neutral PKGenerator
    > > implementations for the most common algorithms (such as sequences),
    > > but this is pretty much all we need.
    > >
    > > Andrus
    > >
    > >
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Dec 12 2005 - 18:25:04 EST