Re: [CDBI] Worknig on Class::DBI::Relationship::IsA

> Hi Peter!

Hi Rhesa. Thanks for the reply. I'm new to cpan as a maintainer. feel
free to correct me if I do something dumb.  See below.

On 2/23/06, Rhesa Rozendaal <perl@xxxxx.xxx> wrote:
> Hi Peter!
>
> Glad to see you're working on IsA :)
>
> Before this trail goes cold, I'll quickly give you my thoughts.
>
> > 1) How to Handle  CDBI Frozen vs Not Frozen versions.  I am thinking
> > that *EVEN* versions numbers on IsA will be compatible with the CDBI
> > Frozen and Odd numbers with later releases.   ?  Is this a good or bad
> > idea? Any better ideas?
>
> I would prefer not having to think about which version I should install. =
On
> top of that, I would _love_ IsA to play nice with Class::DBI::Sweet.
> An even/odd scheme doesn't sound practical to me, not least because the C=
PAN
> shell will generally give you the latest version.

Yes. Aaron explained it to me.. We decided to make it so Cpan installs
the one for the latest stable CDBI -- the frozen one  I presume. and
developement releases will have ".xxxx" appended where xxxx is the
CDBI version it is compatible with but without period, or whatever
works. I will have to rtfm to figuer out how cpan recognizes
developement releases now in case it has changed recently.

So tomorrow i will release .06 and hopefully .06_3014

> > 2) One to One vs Many to One.  -- from my DB  knowledge  I understand
> > IsA rels to be of either 1:1 or M:1 relationship types.  I want to
> > make IsA cascade delete if it is a 1:1.  I'm thinking of doing that by
> > passing an extra arg to the isa call:
> >
> > Music::Artist->is_a(person =3D> 'Music::Person', {one_to_one     =3D> 1=
} );
> > Music::Person->is_a(species =3D> 'HomoSapien', {many_to_one =3D> 1} ); =
# fancy has_a
> >
> > Any objections to this interface? Better ideas?
>
> Can't tell. I only use 1-1, pretty much like might_have. I'd probably lik=
e it
> to default to 1-1.

I think it should default to one_to_one also. So I will just have a
many_to_many flag in case. But most cases you would probaby just use
has_a unless IsA developement takes off and it blooms beautiful
features.

>
> > 3) Are the docs still wrong on usage ? I find that I have to declare
> > which column to "import" from the IsA class in my classes column
> > lists. This may be a good thing as you have some control over methods
> > created for you. The docs say :
> >
> >   Music::Artist->columns(All =3D> qw/artistid alias/);
> >   Music::Artist->is_a(person =3D> 'Music::Person'); # Music::Artist
> > inherits Person accessors
>
> This definitely works for me exactly like it says here, using (the older)=
 0.05.
>
> > But my experience is this:
> >
> >   Music::Artist->columns(All =3D> qw/artistid alias first_name  last_na=
me dob/);
> >
> >   Music::Artist->is_a(person =3D> 'Music::Person'); # Music::Artist onl=
y
> > inherits Person first_name,
> >                                                             #
> > last_name, and dob
>
> No, I have not had this experience at all. Mind you, I've never used the =
0.05
> that's on CPAN at the moment, because it had several issues. The version
> before that (also 0.05) works pretty well though, and doesn't exhibit wha=
t you
> describe here.
>

Ok. It must be the Framework it was running in. I will figure this out.

> > An official test will take care of what is and is not.  I would like to=
 know --
> > What is desired?  Personally I am leaning toward being abel to declare
> > which are inherited.  It could be an arg that defaults to all.
>
> I think having control is nice, see the way might_have works. I would be =
fine
> with having them all imported by default.
>

I like that but makes remapping args trickier. I will look though. I
remeber struggling with remapping might_have args on my "must_have"
relationship but maybe i conquered it.
Will try to use might_have interface if can. However rels need to take args=
.

> >  Also, maybe the issue is that the accessor is created but it does not
> > get put in the "All" colums list and it is causing me problems.
> > Music::Artist->is_a(person =3D> 'Music::Person', { inherit =3D>
> > [first_name, ...] });
> >
> > Thoughts?
>
> That looks good. Personally, I don't see a problem with those accessors n=
ot
> being in All. They're not columns of this object, so the accessors should=
 just
> proxy on to the parent object, in my view.

it  would be cool if they could be like columns in every high level
way.  It makes it play nice with frameworks or Maypole anyway but i
imagine lots of them use iterate through columns.

>
> One thing that was lacking from the 0.05 I'm using was that has_many rela=
tions
> of the parent class were not (properly?) imported into the child. Has_a
> relations on the other hand _are_ imported. I would enjoy having the
> has_many's as well :)
>

This sounds ok to me. A patch would be nice as i may not have time for
a little while.

> The second thing I'd like to see is the removal of the hard-coded referen=
ce to
> 'Class::DBI::search', so that IsA can be made to work with CDBI::Sweet. S=
ee my
> recent post to this list for more details.
>

Yes, for now i will try to call Class::DBI::Sweet::search || ... . A
wihile back i started to write an sql join there and maybe then do a
construct. Didnot need it yet though .  That would probably be a
better long term solution, No?

> Other than these two items, I've been fairly satisfied with IsA sofar: it
> works for what I need from it.

I love it.

> I'm willing to help in testing your new versions. Just let me know what I=
 can do.
>

thanks. will do. Tomorrow morning i'll work on it and get .06 out.
Boss distracted me today.  Off now.

cheers

--
pjs

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi