Thanks! What do you mean by a different meaning, though? User.eager(posts:
proc{|ds| ds.published.limit(5)}) simply tacks on the LIMIT to the Post
load, but I'm having a hard time seeing why anyone would want/use that
behavior?
I think the :eager_limit option would be fine, though - it would probably
also be helpful to be able to specify an :eager_limit_strategy in the same
call.
Chris
On Tuesday, December 8, 2015 at 10:57:09 AM UTC-5, Jeremy Evans wrote:
>
> On Monday, December 7, 2015 at 9:42:54 PM UTC-8, Chris Hanks wrote:
>>
>> Hi -
>>
>> I'm using Sequel in an app that's servicing client requests written in
>> GraphQL. The specifics aren't that important, the basic concept is that I'm
>> dynamically generating eager-loading queries in response to client queries.
>> For example, a query for users and their published posts will build a query
>> that's the equivalent of: User.eager(posts: proc{|ds| ds.published}).all.
>>
>> This has been working well so far, except that now I'm trying to support
>> limits in these eager-loading queries and Sequel isn't really built for it.
>> The eager limiting strategies would be nice but seem to only apply for
>> cases where the :limit option is passed to the association declaration,
>> which unfortunately won't work for me because I need these limits to be
>> dynamic.
>>
>> I'm happy to put together a patch for Sequel to support this, but before
>> I do I wanted to get a sense of whether it'd be considered useful enough to
>> be merged into master, or if there are problems with supporting this that
>> I'm not seeing. The goal would be for a query like User.eager(posts:
>> proc{|ds| ds.published.limit(5)}) to use the same eager limiting strategy
>> that would be used if the User -> Posts association had been declared with
>> a limit of 5.
>>
>
> I'm not opposed to supporting dynamic eager limits, but just appending a
> limit to an eager callback would not work, as that already has a different
> meaning. It's possible you could do something like:
>
> User.eager(posts: proc{|ds| ds.published.clone(:eager_limit=>5)})
>
> and have the association code look for that particular key in ds.opts.
>
> As long as it works and has tests (specs and integration tests) and
> documentation, doesn't change existing behavior, and only requires minor
> modifications to the existing code, I'd say it's likely it would be
> accepted.
>
> Thanks,
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
