this is my problem, I have a ManyToMany association a bit weird. I've been using a JoinTable with a compund PK (with both foreign keys) but now I need to let this join table to allow dupplicate pair entries for foreign keys. I' ve tried adding an extra column "id" in the join table, defining it as the PK instead of using the compound PK but I don't know how I should map this situation or if it is correct or not.
I have an entity called "Training Program" which models a training program used for an runner to prepare a race in wich he/she wants to run. Also I have another entity called "Training Session" which holds the excercises to do in that training session. So a training program is composed by many training sessions (some could be repeated in the same training program) and a training session could be part of many training programs. This data is a template of what a runner really does by which I have a dupplicate hierarchy with the "real" data kept by the runner.
At first I designed it as a usual ManyToMany but now I need dupplicate entries for the aggregation between training program and training session.
My idea was adding an extra id column which will be auto generated using Identity strategy as you said, but I am not sure how to do it and managed the association.
Related your second idea I must say I have used it in another scenario in which I had to store another column which is part of the state of the ManyToMany association.
Which is the best solution from your view?
Thanks for the help!
posted 9 years ago
For your model I would create an TrainingDay Entity that maps to the join table. Then have TrainingProgram - 1-m - TrainingDay - m-1 - TrainingSession. I would assume that you will need to store more information about the day, i.e. I assume to order of the sessions in the program are important, so you would need a day # field, (you would not do 2 longs runs or 2 speed work sessions back to back). You also may have a TrainingDay without a TrainingSession for a rest day. A TrainingDay may even have multiple sessions, a m-1 morningSession and a m-1 afternoonSession, maybe even a m-1 eveningSession for the serious runners.
I understand what you said and it seems to be a pretty good idea but I think it is beyond the scope of my project. If I am not wrong I think that having one hierarchy with training programs and training sessions as templates of what runner should do and a second hierarchy with the the same structure holding what runner really does is enough for this project because it will not be in production. That is the reason why I split the model in two parallel hierarchies.
I like your idea of mapping the join table as an entity I wonder if there is any problem in mapping its PK as an auto generated id and having the fk to the other tables in it. On the other hand what you said about having more information of a day, I created an embeddable object called "TrainingDays" in which I store the days of the week as booleans and a method which says if a day is a training day or not (this in the parallel hierarchy of real data). In the "template" hierarchy I have an attribute in the entity "TrainingProgram" called "#SessionsPerWeek" which must be the same as the number of concrete training days in "TrainingDays".
I think this is an easy approach and enough for the purposes of my project. I would like to know what is your opinion about it .
Don't sweat petty things, or pet sweaty things. But cuddle this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!