[Maypole] Re: Many to Many support for Maypole (patches)

[Yuval Kogman]

--qtZFehHsKgwS5rPz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 26, 2004 at 18:10:05 -0700, steve shapero wrote:
> Hi Yuval and Maypole list--
>=20
> I think I may only now be fully grasping what this (many to many=20
> patches, etc.) is all about.  I've been trying to use a lot of has_many=
=20
> linked tables in Maypole, and the handy factory view_related macro=20
> doesn't work for them... perhaps because many to many are not fully=20
> supported, and that's why you wrote this stuff...?

The changes I made to the macros is to support the addition of new items
and they're removal from many to many tables. Since getting many to many
items is the same as getting has_many items, it should display with the
original item too.

If you have a page up, and a CDBI table definition for that that we can
see, I can probably help you debug that, since lots of the hell I went
through is with getting maypole to ask for the right stuff. Hence the
->mapped_class method addition to Class::DBI::Relationship::HasMany.

> All I want to be able to do is show a page with all the relevant info
> about a product -- which comes from all my various lookup tables... Am
> I better off using CDBI and making my own templates and just hacking
> instead of trying to get Maypole to do all this?  given that i'm much
> more of a desperate perl hacker rather than a true programmer.

I think you should be able to do this with just changing the templates.
TT is surprisingly easy to hack at, because it's deliberately limited to
the extent that you have to rely on some precanned stuff, yet complex
enough to be flexible.

> for those of you on the maypole list here that haven't been following=20
> my learning curve on the CDBI list, here's my scenario:
>=20
> i have these tables (all of which have single column PKs):
> Track->has_many(artists =3D> [Trackartist =3D> 'artistid']);
> Track->has_many(genres =3D> [Trackgenre' =3D> 'genreid']);
>=20
> Trackartist->has_a(trackid =3D> Track);
> Trackartist->has_a(artistid =3D> Recordingas);
>=20
> Recordingas->has_a(personid =3D> Person);
> Recordingas->has_many(trackid =3D> [Trackartist =3D> trackid]);

why not 'tracks', and 'person'? Appending 'id' is counter-intuitive,
since due to inflation you will not be getting an ID. OTOH, [Trackartist
=3D> 'trackid'] should not change, because your schema won't allow you to
call it 'track'. But use strict; because if [Trackartist =3D> trackid]
works, a lot of other stuff you don't want would too... =3D)

> Person->has_many(aliases =3D> Recordingas);
>=20
> so imagine i have data like this:
>=20
> Person: DJ Bedroom
> Recording As: Kite Flyer
> tracks by DJ Bedroom recording as Kite Flyer:
> clouds in the sky (genres: techno, rave)
> more wind blows (genres: techno, rave)
> Recording As: Reflexes
> tracks by DJ Bedroom recording as Reflexes:
> quick (genres: hiphop)
> slow (genres: hiphop, instrumentals)
>=20
> i want to display all this data -- really from the perspective of any=20
> of these items: track, genre, recording as, etc. -- and have all the=20
> other interesting data inflated in the same template.

Right.. It's all in the template, i think. You should be able to pull it
off. Look at the ugly stuff my changes to view_related are doing to
figure out some stuff. You can use Template::Plugin::Class to call class
methods, which is what you need to extract useful data out of CDBI
classes.

If you FOR loop on the aliases accessor, and then FOR loop on the
tracks, you should be able to display that. Note that this relationship
is not really a many to many one, it's a 2 level deep one to many
relationship.

I must say this schema is not really intuitive, though.

What if one artist had many aliases, and many aliases had many tracks -
i think that works better. Then you do the same for loop, just
display_related for each alias the artist has, and then you get
something that's properly editable.

This is a translation of your real schema, right? Maybe you'd like to
share it, if you are not bound legally to not do so, and people can give
you feedback, as well as help debug it?

> i'm sort of banging my head against the wall but i feel like maypole is=
=20
> such a cool tool i'd love to use it.  it may be too advanced for me=20
> alas... i'm not skilled enough to hack CDBI or Maypole code itself if=20
> that's what would be required, which i sort of am picking up on from=20
> Yuval's post.  i tried setting up beerdb with the "a pub has beers on=20
> handpumps" and the sub related { "pubs" } line in BeerDB::Beer, but it=20
> didn't do anything cool.

What do you mean by that? Were you not able to add beers to pubs and
vice versa? My MySQL server was brutally shot yesterday, I'll try to get
it back up, and I'll make the full source of stuff available.

> i wonder if my data is too complicated?  i wonder if i should just
> have some gnarly flat tables and have a disgusting schema so i don't
> have to learn to write more code?

Disgusting schemas usually turn out to be not worth it. The added
complexity of updates due to data redundancy is usually so bad, you
would opt to change it later anyway.

--=20
 ()  Yuval Kogman <nothingmuch@woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: uhm, no, I think I'll sit this one out..: neeyah!


--qtZFehHsKgwS5rPz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFA3QjPVCwRwOvSdBgRAl51AKDDJS4zkkCb4NhHWuG0WY8AqVP4uACfeUak
PKIp+Z88I7HkQ3sxYO//ZoY=
=zUVG
-----END PGP SIGNATURE-----

--qtZFehHsKgwS5rPz--