Hi Andy, On 10/31/07, Andy Brody ([EMAIL PROTECTED]) wrote:
>I'm using an intermediate table of Activities to relate Musicians, >Instruments, and Groups. Is there a good way to select groups from the >musician's activities? I've been doing stuff like [act.group for act >in theMusician.activity_set.all()]. This works pretty well, except >that there are duplicates if a musician plays more than one instrument >in a group, and merely doing set( the_above ) doesn't get rid of them >even though group1==group2 evaluates to True. > >Is there some better way to do this? It seems strange to be trying to >remove the duplicates at this level rather than at the SQL level with >a distinct(). The resulting SQL (which I don't want to write myself) >should be something like: > >SELECT DISTINCT * >FROM `app_group` >WHERE `id` >IN ( > >SELECT `group_id` >FROM `app_activity` >WHERE `musician_id` = 1 Interesting, you're trying to solve a similar problem I've been working on for a while (not because its that difficult, but lack of time for that project). The differences between our tasks are based upon a couple of more layers. Not only am I tracking musicians, instruments and activities but also events, stages, band-instances and such (I'm a photographer and manage other photogs, and photos, at larger events like festivals... where musicians and band compositions change on an hourly basis it seems). I abandoned trying to make this a beautifully relational stage::band::musician structure for a significantly simpler heriarchical, keyword-based architecture. I put some of the logic into the heirarcy to solve problems like bands named after musicians via parent/child relationships. It is still an M2M design, but it is no longer bound by static relationships. This also solved other problems I was trying to work-out, which included ratings, sub-activities/subjects as well as parallel attributes i.e. something applicable to multiple categorizations i.e. musicians that play in multiple bands over time. Finally, and the best part, I can add or change new attributes via keywords without having to re-configure the architecture. 8^) In my models, I have my Assets (images) and my Keywords (self-referential for heirarchy) and there is a M2M relationship between them. The heirarcy is essential i.e. the keyword musician is parent to all musicians. So if I don't care _which_ musician is playing a Djembe, or I want images of a Djembe and a Bagpipe (yes, I've seen it), I _can_ do that easily. Anyway, I thought I'd pass on the thought of attacking the problem from a different viewpoint that may be more flexible over time. I probably didn't describe the solution I'm using well, but hopefuly some of it makes sense. Of course, there are other solutions to this problem I just happen to like this because it is pretty simple (for me anyways). Scott --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
