Issues with catenating the results of two queries + will_paginate

(Rails 4, Ruby 2)

I have two functions which query the database. Both yield a set of model
objects. These two sets should be catenated and presented to the user
using the will_paginate Gem. I think I understand now how to do it, but
a few issues with this are still puzzling me.

Here are the query functions:

def the_other_dicts_of_same_user(d)
User.find_by_id(d.user_id).dicts.where(“id != #{d.id}”)
end

def public_dicts_of_other_users(d)
Dict.where(“user_id != #{d.user_id} and world_readable”)
end

Both yield a series of Dict objects. The result of the first query is of
type Dict::ActiveRecord_AssociationRelation and the result of the second
query is of type Dict::ActiveRecord_Relation

I guess I get different data types here, because I start with User in
the first case and with Dict in the second case.

As a side note: I could have written the first query alternatively as

Dict.where(“user_id = #{d.user_id} and id != #{d.user_id}”)

Would this be better?

Anyway, I catenate the results,

@dicts=the_other_dicts_of_same_user(d)+public_dicts_of_other_users(d)

which yields again a Dict::ActiveRecord_Relation . Now I apply
pagination:

@[email protected](…)

This yields the error message, that paginate is not defined for objects
of type Array.

I was able to get around this error, by doing a

require ‘will_paginate/array’

as a first line in my controller, but I wonder: Why do I get this error?
@dicts is NOT an array (I logged @dicts.class.to_s to be sure of this),
and I would have expected to work it in a ActiveRecord_Relation.

Could someone please kindly explain this observed behaviour to me?

On Aug 16, 2014, at 6:03 AM, Ronald F. wrote:

User.find_by_id(d.user_id).dicts.where(“id != #{d.id}”)
I guess I get different data types here, because I start with User in
@dicts=the_other_dicts_of_same_user(d)+public_dicts_of_other_users(d)

require ‘will_paginate/array’

as a first line in my controller, but I wonder: Why do I get this error?
@dicts is NOT an array (I logged @dicts.class.to_s to be sure of this),
and I would have expected to work it in a ActiveRecord_Relation.

Could someone please kindly explain this observed behaviour to me?

I suspect that it is because a Relation is not an Array, it’s more of a
scope. It can be iterated over, because it extends Enumerable, but that
does not make it an array. But adding the two together must (I am
guessing here) cause them to both be evaluated as arrays before the
addition can succeed. When you do to_a on a Relation (either kind) it
loses its magic lazy-loading behavior, and the elements are found and
placed into the array. The whole point of a Relation is that the found
records inside it are not loaded into memory until they are actually
asked for more formally. This makes it much faster (and allows for
further chaining) in a scope.

Walter

On 16 August 2014 11:03, Ronald F. [email protected] wrote:

User.find_by_id(d.user_id).dicts.where("id != #{d.id}")

I guess I get different data types here, because I start with User in
the first case and with Dict in the second case.

As a side note: I could have written the first query alternatively as

Dict.where(“user_id = #{d.user_id} and id != #{d.user_id}”)

Would it be possible to combine the two queries into one - Dict.where(
… or … )? Then you would not need to concatenate them.

Colin

Walter D. wrote in post #1155317:

But adding the two together must (I am
guessing here) cause them to both be evaluated as arrays before the
addition can succeed.

I don’t think this is the case. As I said, I also logged the object
AFTER adding them together, and it still is a
Dict::ActiveRecord_Relation. The conversion into an Array must come
after that, and this means it must happen inside paginate().

Ronald

On Aug 16, 2014, at 9:42 AM, Ronald F. wrote:

Walter D. wrote in post #1155317:

But adding the two together must (I am
guessing here) cause them to both be evaluated as arrays before the
addition can succeed.

I don’t think this is the case. As I said, I also logged the object
AFTER adding them together, and it still is a
Dict::ActiveRecord_Relation. The conversion into an Array must come
after that, and this means it must happen inside paginate().

Is it possible that you are getting this:

[ ActiveRecord_Relation, ActiveRecord_AssociationRelation ]

(an array of the outermost objects) rather than this:

[ #Record 1, #Record 2, … ]

when it gets to pagination?

Walter

Walter D. wrote in post #1155322:

On Aug 16, 2014, at 9:42 AM, Ronald F. wrote:

Walter D. wrote in post #1155317:

But adding the two together must (I am
guessing here) cause them to both be evaluated as arrays before the
addition can succeed.

I don’t think this is the case. As I said, I also logged the object
AFTER adding them together, and it still is a
Dict::ActiveRecord_Relation. The conversion into an Array must come
after that, and this means it must happen inside paginate().

Is it possible that you are getting this:

[ ActiveRecord_Relation, ActiveRecord_AssociationRelation ]

No, because I printed .class.to_s to the object after catenation, and if
it would be an array of whatever content, this would have printed
“Array”, but it printed “Dict::ActiveRecord_Relation”.

That’s why I conclude that the conversion to an Array must happen within
the paginate method itself.

Ronald

Colin L. wrote in post #1155319:

On 16 August 2014 11:03, Ronald F. [email protected] wrote:
Would it be possible to combine the two queries into one - Dict.where(
… or … )? Then you would not need to concatenate them.

Technically, yes, and it likely would be a performance improvement too.
From a designer’s viewpoint, I don’t like this solution so much, because
the individual parts are used in different contexts too, and it means I
would have code duplication here, but maybe I will give it a try.

Ronald

On Aug 16, 2014, at 7:45 AM, Ronald F. [email protected]
wrote:

and it means I
would have code duplication here, but maybe I will give it a try.

Actually, you can build the relations separately, and then combine them
with .or, before accessing rows of the result. So you probably do not
have get code duplication from that approach.