Find distinct values in an array of database results

My problem is similar to Distinct selection - Rails - Ruby-Forum, but I
don’t understand how the asker solved the problem.

I have a model called issues. It returns results that contain a field
called “status”. The results might look like this:

open
open
closed
in progress
open
open

How can I use the “uniq” method on the model in order to return a unique
list of statuses like this:

open
closed
in progress

In addition to my question above, I’d also like to apply the equivalent
of a ‘where’ clause without forcing another SQL query, in order to get
all the columns for “issues” where “status=open”. The results would be:

1, open, fred
2, open, john
5, open, john
6, open, sara

On Wed, Apr 14, 2010 at 11:14 PM, joe mejoe [email protected]
wrote:

In addition to my question above, I’d also like to apply the equivalent
of a ‘where’ clause without forcing another SQL query, in order to get

modify this as needed

results = Issue.find(…)

statuses = results.collect(&:status).uniq.sort

open_issues = results.collect { |i| i.status == ‘open’ }

I suggest you read up on the Array class and its methods
collect, uniq and sort which I used here.

Have fun.

If I may jump in, I’m interested in understanding why you would do this
kind of database job with Ruby vs. an extra SQL query.
I had the feeling that it would be wiser (and would execute faster) to
delegate the job to the database engine

But I’m kind of amateur.

Thanks to anyone who is willing to put some light for me

Christophe

Le 15 avr. 2010 à 10:01, Franz S. a écrit :

Christophe D. wrote:

If I may jump in, I’m interested in understanding why you would do this
kind of database job with Ruby vs. an extra SQL query.
I had the feeling that it would be wiser (and would execute faster) to
delegate the job to the database engine

I agree. This is a job for SELECT DISTINCT, unless you’ve already got
the recordset stored from a previous operation.

In general, do your DB queries on the DB side.

But I’m kind of amateur.

Thanks to anyone who is willing to put some light for me

Light: many Rails developers don’t know how to use a DB properly. :slight_smile:

Christophe

Le 15 avr. 2010 � 10:01, Franz S. a �crit :

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sometimes you’re not querying a database (for example a REST service
that returns a json result). Specially in web applications.

[Please quote when replying, so we know what in particular you’re
responding to.]

Vincent M. wrote:

Sometimes you’re not querying a database (for example a REST service
that returns a json result). Specially in web applications.

True. But where you have a database, you should use it. :slight_smile:

Especially in Web applications? I don’t know. I think I’ve used more
non-Web apps that query Web services than Web apps that do likewise.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On Mon, Apr 26, 2010 at 10:42 PM, Marnen Laibow-Koser
[email protected] wrote:

[Please quote when replying, so we know what in particular you’re
responding to.]

Vincent M. wrote:

Sometimes you’re not querying a database (for example a REST service
that returns a json result). Specially in web applications.

True. But where you have a database, you should use it. :slight_smile:

Sure, however, the original poster specifically wanted to avoid querying
the
database twice, which is why the solution ended up Ruby side.

Franz S. wrote:

On Mon, Apr 26, 2010 at 10:42 PM, Marnen Laibow-Koser
[email protected] wrote:

[Please quote when replying, so we know what in particular you’re
responding to.]

Vincent M. wrote:

Sometimes you’re not querying a database (for example a REST service
that returns a json result). Specially in web applications.

True. �But where you have a database, you should use it. :slight_smile:

Sure, however, the original poster specifically wanted to avoid querying
the
database twice, which is why the solution ended up Ruby side.

As far as I can tell, the OP asked two unrelated questions. I only
answered one of them.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]