>
> Here are a couple ways you could work around it:
>
Thank you for work-arounds.
It is possible in a future version of Sequel we could automatically set a
> server on the eager dataset based on the server of the current dataset.
> That does have the potential to break backwards compatibility in some
> cases, though, so it may be best added as a non-default option.
I think, it's intuitive behavior. I mean… what is goal for requesting
`Artist` from one server and `eager` (association) `albums` from another?
It looks like data-braking behavior.
On Wednesday, February 13, 2019 at 12:44:56 AM UTC+3, Jeremy Evans wrote:
>
> On Tuesday, February 12, 2019 at 1:14:18 PM UTC-8, Alexander Popov wrote:
>>
>> Hello!
>>
>> I have problems, and I think, it can be resolved in Sequel:
>>
>> The query like this works correctly:
>>
>> Artist.eager_graph(:albums).server(:replica).all
>>
>> But with regular `eager` it fails. I think, because it makes eager
>> requests to default server instead of specified (`replica` in this example).
>>
>
> This is because a different dataset is used for the eager loads. Here are
> a couple ways you could work around it:
>
> Artist.eager(albums: proc{|ds| ds.server(:replica)}).server(:replica).all
>
> or using server_block extension:
>
> DB.with_server(:replica) do
> Artist.eager(:albums).all
> end
>
> It is possible in a future version of Sequel we could automatically set a
> server on the eager dataset based on the server of the current dataset.
> That does have the potential to break backwards compatibility in some
> cases, though, so it may be best added as a non-default option.
>
> 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 https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
