Having a problem figuring out how to structure this... Nesting issue

[John Sanderbeck]

I'm working on a project that has the following setup

I have a table called Assessment

for each assessment there can be different reasons and consequences defined for that assessment

then for each assessment the teacher takes multiple data entries over a period of time

each data entry can choose multiple reasons and consequences from the ones defined in the assessment

So you have assessment

has_many :reasons

accepts_nested_attributes_for :reasons

has_many :consequences

accepts_nested_attributes_for :consequences

has_many :data_entries

accepts_nested_attributes_for :data_entries

Then reasons

belongs_to :assessment

has_and_belongs_to_many :data_entries

Then consequences

belongs_to :assessment

has_and_belongs_to_many :data_entries

Finally data_entries

belong to assessment

has_and_belongs_to_many :reasons

has_and_belongs_to_many :consequences

There is also a join table for reasons to data_entries, and consequences to data_entries

The nested table works fine for the reasons, consequences, and the base data_entries

however what I cannot get to work is the reasons and consequences chosen in the data_entries

what appears to be happening in params is that assessment comes back with data_entries_attributes under it

however there is also a data_entry param coming back as well, so it is not part of assessment, so the nest is wrong somehow...

I have this working in other places however this nest is one level deeper than the others...

The way I have the nested form section setup is this...

  <td>

    <div class="multi-column">

      <ul>

        <% @assessment.reasons.each do |reason| -%>

            <ul>

              <%= check_box_tag('data_entry[reason_ids][]', reason.id, @assessment.reason_ids.include?(reason.id), :multiple => true) %>

              <span rel="tooltip" title="<%= reason.assessment_id %>"><%= reason.name %></span>

            </ul>

        <% end %>

      </ul>

    </div>

  </td>

  <td>

    <div class="multi-column">

      <ul>

        <% @assessment.consequences.each do |consequence| -%>

            <ul>

              <%= check_box_tag('data_entry[consequence_ids][]', consequence.id, @assessment.consequence_ids.include?(consequence.id), :multiple => true) %>

              <span rel="tooltip" title="<%= consequence.assessment_id %>"><%= consequence.name %></span>

            </ul>

        <% end %>

      </ul>

    </div>

  </td>

John

[Colin Law]

On Wed, 24 Oct 2018 at 12:12, John Sanderbeck <band...@gmail.com> wrote:
>
> I'm working on a project that has the following setup
>
> I have a table called Assessment
>
> for each assessment there can be different reasons and consequences defined for that assessment
>
> then for each assessment the teacher takes multiple data entries over a period of time
>
> each data entry can choose multiple reasons and consequences from the ones defined in the assessment
>
> So you have assessment
> has_many :reasons
> accepts_nested_attributes_for :reasons
> has_many :consequences
> accepts_nested_attributes_for :consequences
> has_many :data_entries
> accepts_nested_attributes_for :data_entries
>
> Then reasons
> belongs_to :assessment
> has_and_belongs_to_many :data_entries

If I understand the problem correctly then you don't need that, you
can do has_many data_entries through assessment and in data_entries
the same thing the other way round. That is assuming that all the
data_entries for a reason are those defined for the assessment it
belongs to. Then to get the data_entries for a reason you use
reason.assesment.data_entries. Similarly for the other classes.

Colin

[John Sanderbeck]

Hmmm...   That may work...

I would always be accessing assessment.data_entries for any lists or views. Reasons and Consequences are basically select criteria for each data entry.

I would never reference reason.data_entries or consequence.data_entries

a has_many :data_entries, :through: :assessment may work though...  Let me give that a shot...

Now to figure out how to structure it...  :-)

[Colin Law]

Certainly you only need to specify the associations you need to use.

Colin

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/749f9533-d198-4f8a-a2a5-98c6c5368452%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[John Sanderbeck]

One question though...   For a through association, I have to have a join table for the association.

So since I want Assessment to be my parent, should I do a join like this?

Create a data_entry table and a data_records join table and then have the association be

assessment 

  has_many :data_entries, through: :data_records

and data_entries

  has_many :assessments, through: :data_records

However while this may be structured better, I would still have the issue with the reason and consequence associations...

John

[Colin Law]

On Wed, 24 Oct 2018 at 23:21, John Sanderbeck <band...@gmail.com> wrote:

One question though...   For a through association, I have to have a join table for the association.

No, if you say

Reason has_many :data_entries, :through: :assessment

then since you already have reason belongs_to assessment so if you have a Reason in @reason then you can say

@assessment = @reason.assessment.

Also you already have assessment has_many data_entries so you can say

@data_entries = @assessment.data_entries

Therefore you can get direct from a reason to the associated data_entries using

@data_entries = @reason.assessment.data_entries

No need for an additional join table.

Have a look at the Rails Guide on Associations for more detail.

You might also like to work through the tutorial at railstutorial.org (which is free to use online) which should cover this and all the other basics of Rails.

Colin

Colin