Sunday, 29 September 2013

Query for distinct instance of model + one other field

Query for distinct instance of model + one other field

I have a model called Evaluation. When an evaluation is created, an
eval_number is created with it. There are many evaluations with the same
eval_number.
Here's an example:
- !ruby/object:Evaluation
attributes:
id: 2023
score: 3
created_at: 2013-09-08 13:10:53.000000000 Z
updated_at: 2013-09-08 13:10:53.000000000 Z
student_id: 26
goal_id: 50
eval_number: 33
- !ruby/object:Evaluation
attributes:
id: 2099
score: 4
created_at: 2013-09-08 13:19:12.000000000 Z
updated_at: 2013-09-08 13:19:12.000000000 Z
student_id: 26
goal_id: 36
eval_number: 34
- !ruby/object:Evaluation
attributes:
id: 2100
score: 3
created_at: 2013-09-08 13:19:12.000000000 Z
updated_at: 2013-09-08 13:19:12.000000000 Z
student_id: 26
goal_id: 37
eval_number: 34
- !ruby/object:Evaluation
attributes:
id: 2101
score: 4
created_at: 2013-09-08 13:19:12.000000000 Z
updated_at: 2013-09-08 13:19:12.000000000 Z
student_id: 26
goal_id: 38
eval_number: 34
In a view, I want to show the date that a given evaluation was created in
a table header. It should look like this:
date_1 | date_2 | date_3 | date_4 | etc..
To do this, I need to get distinct evaluation_numbers + the created_at
dates that go with them. I thought that this would help, but it's
returning more than one record per eval_number with this code:
def eval_date(i)
evals = self.goals.first.evaluations
eval = evals.select("distinct(eval_number), created_at").all[i]
eval.created_at.to_date
end
It seems like distinct eval_numbers are being selected, but also distinct
created_at columns (which of course are all different). This makes the
.all[i] basically useless as it's finding the [0], [1], [2], etc element
correctly - but there are far more than whatever the given number of i is
in the returned array.
I want to find a distinct eval_number and load only the created_date that
goes with it. I think I could load the whole record with all attributes,
but I don't need them, so I'd rather not.

No comments:

Post a Comment