To beat a dying horse a bit more ...
I think it is OK to "clutter" the modeler a little bit if it can save in
other ways. With regards to PK generation, to get Cayenne to work with
our legacy schema I had to create a subclass of SybaseAdatper (which I
put in a separate package) and override the createPkGenerator() method
to instantiate my new PK class. I also had to copy types.xml and create
my new PK class. Then I had to enter that new adapter into the modeler.
It would've been cleaner if I could've just specified SybaseAdapter (as
normal) and then specify a custom PK class in the modeler. I don't see
that subclassing and copying an identical types.xml file is better
(especially if types.xml changes for the existing SybaseAdapter -- I'll
most likely not notice that change). It certainly felt more convoluted.
If we could change the modeler to allow specifying a custom PK class and
then modify the adapter code to instantiate it, that would be super.
Then you could specify a PostgreSQL (or any other DB) PK generator that
used the old table way or the new sequence way.
Thoughts?
Thanks,
/dev/mrg
-----Original Message-----
From: Cris Daniluk [mailto:cris.danilu..mail.com]
Sent: Monday, December 12, 2005 6:25 PM
To: cayenne-deve..bjectstyle.org
Subject: 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 : Tue Dec 13 2005 - 10:15:53 EST