On Tuesday, February 12, 2019 at 2:12:51 PM UTC-8, Alexander Popov wrote: > > 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. >
class Artist < Sequel::Model(DB1) end class Album < Sequel::Model(DB2) end Eager loading via #eager works just fine in this scenario, but there is no indication that DB1 and DB2 are using the same sharding configuration. Any automatically setting of the server to eagerly loaded datasets would have to check the Database object is the same for both datasets. It's also possible in a true sharded configuration with the same Database object, that using the same shard for the eager load could cause backwards compatibility issues. Let's say you had all albums in the primary (:default) database, and you sharded your artists table to multiple databases, but the albums table doesn't exist in the artist database shards: Artist.eager(:albums).server(:artist1).all I'm not saying that is a particularly likely scenario, but it is a case where changing the behavior would break things. 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.
