Joint Tables (1st part)

[mlfreer]

Experiments_Sessions: Yes, we do not need to have a join table, but need to add the _experimentid to the sessions_table

later will possibly need other atributes in the table

Sessions_Subjects_Joint_Table:

• session_id
• subject_id
• registered
• shown_up
• participated

Experiment_Subject_Joint_Table (definition of the subject pool):

• experiment_id
• subject_id
• invited
• participated

as far as i've got such tables are necessary for the pages we need to do the most priority has experiments_session_joint_table\

Jeff do you have enough free time to finish it?

[ppodolsky]

Misha, are you sure that we need many-to-many association between experiments and sessions? Can one session belong to many experiments?

[mlfreer]

thanks! you're right!

[jrhorn424]

On 11 Mar 2014, at 1:02, Pasha Podolsky wrote:

Misha, are you sure that we need many-to-many association between experiments and sessions? Can one session belong to many experiments?

Good catch!

Jeffrey Horn http://hello.jrhorn.me/

[ppodolsky]

Misha, is it correct that any subject can participate in the only session and therefore the only experiment? Then, we need little cnahges in schema: SessionsSubjects will have three column: session_id, user_id, participated The existence of record in SessionsSubject will mean that Subject registred to Session. If Subject came to the session, we would set participated to true ExperimentsSubjects will have two column: experiment_id, user_id The existence of record in ExperimentsSubjects will mean that Subject assigned to Experiment.

[mlfreer]

subject can participate in no more than 1 session of each experiment so he can take part in any number of experiments, but for each of them no more than in 1 session

about participated: your logic doesn't work, cause sometimes we have to bump subjects: so they shown up, we give them 5$ and let them go, so they registered, shown up but not participated or they can just register and do not come, whats why we need all these 3 different attributes

[jrhorn424]

Please start pushing to branches and submitting pull requests. That allows me to keep track of code as it comes in. We also have a CI service that will warn you before merges if there's an error. I'm currently setting that up to automatically push to staging once it's green. Small, focused pull requests mean we can merge with confidence.

[jrhorn424]

And please don't close issues until the code supporting the feature is in the develop branch, passed CI, and (eventually) deployed.

[jrhorn424]

If you want to focus on tasks, you can use the filters and columns at Huboard. Misha and I are using that for project planning, so it might help you.

[jrhorn424]

Closed by #26