I think what you are saying is that basically you need to qualify columns if you think Dataset#qualify will happen later in the chain and you don't want it to change the current columns...
Sorry for the bad example, by "computed" I mean simply any computed column like COUNT(*) as "count", doesn't really matter. On Wednesday, June 24, 2020 at 9:31:10 PM UTC+3, Jeremy Evans wrote: > > On Wednesday, June 24, 2020 at 10:55:18 AM UTC-7, Aryk Grosz wrote: >> >> I have a sequel pagination library, that runs "qualify" and changes >> previous conditions earlier up in the chain causing the sql too fail. >> >> What is the best practice here? >> >> Is there a way for me to do: >> >> User.select(<computed>.as(:is_nearby)).order(:is_nearby) >> >> and *not* be worried about "qualify" being run later in the chain and >> making the sql no longer valid. >> >> I've tried: >> >> User.select(<computed>.as(:is_nearby)).order(Sequel[:is_nearby]).qualify >> >> User.select(<computed>.as(:is_nearby)).order(Sequel[:is_nearby].as(:is_nearby)).qualify >> >> #qualify is still applying a condition on it. >> > > I'm not sure what exact problem you are running into, as you don't specify > what <computed> is. Making sure your examples are self contained before > posting them makes it easier to provide support. > > If you don't want #qualify to qualify an identifier, the identifier needs > to be already qualified, or you can use literal SQL instead of an > identifier. > > An alternative approach would be not using #qualify, and manually > qualifying identifiers that would be ambiguous. > > 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 view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/ba423d4b-4f6c-42c9-89c5-2927af24aa14o%40googlegroups.com.
