After talking to a colleague apparently Grails version 1.1 does cater for many to many relationships (I've been using 1.04 for my project so far). Version 1.1 is now in Release Candidate 1 so I'll grab this and have a look.
In the meantime I think I'll continue with the new branch and work with Entrant objects. Old school I know but as they say there's no school like the old school..
Floreat Pica
Sunday 22 February 2009
Thursday 19 February 2009
Many to Many Relationships
Over the past few days I've been scratching my head over the competition project. Initially I had decided that a user would just enter their name and email and select a competition from a drop down box... easy right? Then it was suggested to me that there may be multiple open competitions at any one time. In this case ideally the user could select the competitions they want to enter using checkboxes. Still I thought this would be simple but it bought me face to face with many to many relationships.
After much grief and experimentation I was about to give in and go back to plan A when I found this article by Scott Davis. Here he explains how he had been given advice that there is no such thing as a many to many relationship instead there is usually another class that is missed when considering how the objects interact. With this sage like advice I've decided to reassess the competition design.
Now I will use another class (the Entrant) to hold name, email and a set of Entry objects. These entry objects will each map to a competition thereby avoiding the need for a many to many relationship between entries and competitions. Now an entrant can have multiple entries ( 1 to m) and each competition has multiple entries (1 to m).
Stay tuned for news on how this progesses...
After much grief and experimentation I was about to give in and go back to plan A when I found this article by Scott Davis. Here he explains how he had been given advice that there is no such thing as a many to many relationship instead there is usually another class that is missed when considering how the objects interact. With this sage like advice I've decided to reassess the competition design.
Now I will use another class (the Entrant) to hold name, email and a set of Entry objects. These entry objects will each map to a competition thereby avoiding the need for a many to many relationship between entries and competitions. Now an entrant can have multiple entries ( 1 to m) and each competition has multiple entries (1 to m).
Stay tuned for news on how this progesses...
Tuesday 3 February 2009
Comp update
The biggest problem I have been having with the competition code is how to handle prizes and their relationship with competitions. Do the admin users create the prizes as they create the competition? Do they create prizes in a completely separate prize and then add it to the competition? So much choice!
I guess the lesson learned here was the value of a pencil and piece of paper. I drew out roughly what I was after and whilst the answer didn't come to me straight away it was much easier to visualise. So I've decided to let the admin user create the comp and then on completion of that process add the prizes in the next step. I think this will work so now its time to think about the views. At last progress is being made...
I guess the lesson learned here was the value of a pencil and piece of paper. I drew out roughly what I was after and whilst the answer didn't come to me straight away it was much easier to visualise. So I've decided to let the admin user create the comp and then on completion of that process add the prizes in the next step. I think this will work so now its time to think about the views. At last progress is being made...
Subscribe to:
Posts (Atom)