Well, the final choice is always yours. :D IMO, creting a Model to simulate HABTM would be rough on the programming side, since you have to define extra logic to save them (e.g., for each assoc, you need to save it). This is not the case when you use pure HABTM, just throw in an array, and Cake does the rest.
I'm just being easy. But easy doesn't exactly correct/good. On a note: if you have several models that behaves similarly, it might well considering OOP inheritance. That way, you reduce DRY (don't repeat yourselft), which is one of the reason OOP is invented. -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of clemos Sent: 29 Nopember 2006 0:08 To: [email protected] Subject: Re: Multiple HATBM (n:n) using the same model for different purposes hi adrian and marcelo you're probably right about the "feasibility" of customizing HABTM infos. then, to me, the solution would rather to make one single additional model (say : EventStoreRelation) that would "simulate" the HABTM table : it would belongTo both one Event and one Store, and would also have a column like "type", that would define the relationship between the event and the store, and so on... these relationships can be defined as an array is this model (like I said in my previous post). then if you have to add a "type", you don't even have to make a new table or a new model, you just have to add an entry in this array... because it looks like the relationships actually aren't that different, and anyway this additionnal model can probably handle different features for the different "types"... and my experience makes me think it's better to try to have as less models as possible, especially if several models actually have a similar behaviour. or maybe I misunderstood you ? +++++++ clemos On 11/28/06, Adrian Godong <[EMAIL PROTECTED]> wrote: > > Is the second solution feasible? I mean AFAIK, if you stick to the default > CakePHP implementation of HABTM, you can't have any other field other than > the two PK/FK fields. > > Take a look at how CakePHP handles saving HABTM assoc from the manual. > > If you want to "relate" model A with model B, when saving model A, you will > need to accompany it with array of model B _id's_. There's no extra data > saved here. > > Unless, of course, you have a "fake" HABTM model. > > My proposed solution would be the first one. Why? > 1. It provide a clear disctinction between each relation. Those relations > are _different_, right? > 2. It provide a more cohesive structure. When, just in case, you need to add > another relation between event and store (say, stores that sells/has rare > tickets), you won't need to touch the currently running code. You can say > it's a more pluggable architecture (because it is simpler to add things > later). > 3. It's easier to do the associations (one for each assoc), access data > (don't need to process anything on the logic, everything's done on the > database), and edit (you know that Cake deletes all of the HABTM relation > for a specific ID before inserting new ones -- that is, unless you managed > to create a custom update/save query). > > Just my 2 cents. > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf > Of clemos > Sent: 28 Nopember 2006 18:26 > To: [email protected] > Subject: Re: Multiple HATBM (n:n) using the same model for different > purposes > > > hi marcelo > > I'm not really a guru, but your second solution looks the best to me. > Then, if the "relationship_types" don't need to be editable, you can > just let them "static". > > For exemple you can define them as an array in your Event model : > > $store_types = array( > 0 => "regular seller", > 1 => "VIP seller", > 2 => "partner" > ); > > And you have an int column in your habtm table called store_type or > something > At least, that's what I would do. > The nice thing is you can use this "store_types" array in your form > with selectTag > > +++++++ > clemos > > On 11/27/06, Marcelo de Moraes Serpa <[EMAIL PROTECTED]> wrote: > > Guys, I really need a hand here! > > > > Let's say I've got two models: > > > > * Event -> Represents a party event > > * Store -> A store where the user could buy a ticket to the party > > > > A user wants to go to a particular event. So, he enter the event > > informations page and sees a list of "stores" (places) where he/she can > buy > > tickets for this event: > > > > Event information screen: > > > > -------------------------------- > > Event Name > > (...other informations...) > > > > Where to buy regular tickets: > > * R&B Co. > > * Shopping 1 > > > > Whrere to buy VIP tickets: > > * Carmen Steffens > > * VIP store > > > > Companies that are supporting this event: > > * Carmen Steffens > > * VIP store > > > > > > -------------------------------- > > > > As you can see, there are 3 lists of store for each event. The store where > > to buy a regular ticket, the store where to buy a VIP ticket and the > > "stores" that are supporting this event. And here's where I get confused > on > > how to model this kind of association. > > > > I see 3 possible solutions for this problem: > > > > 1) having a n:n relationship table for each of the HABTM associations > > (events_storeregularticket, events_supportstores... each having a event_id > > and store_id of course) > > 2) having only one "general" events_stores whith a "relationship_type" > field > > so I could filter the correspondent records for each of HABTM > relationship; > > 3) Fake RoR's throughassociation (see Felix's post here: > > > http://www.thinkingphp.org/2006/10/26/modeling-relationships-in-cakephp-faki > ng-rails-throughassociation/ > > ) transforming each of the HABTM association into an entitity itself, so I > > would have a model (and a corresponding table) for: > > * PlacesToBuyRegularTickets model; > > * PlacesToBuyVipTickets model; > > * EventSupportingStores model; > > > > Particulary, I find the second one to be a more clean solution as I keep > > only one table, but I see that I would need to create another table to > keep > > the kinds of relationships :/ > > > > I'm really confused on the best way to model this in Cake. What would you > > do/What have you done on your projects? > > > > Thanks in advance! > > > > Marcelo. > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
