On Thursday, August 29, 2013 2:27:09 PM UTC-7, Alex Vinnik wrote: > We run into a problem due to change in select_more behavior in 3.48. > > - > > Dataset#select_more becomes an alias for select_append. > > > I will try to illustrate the problem. Let's assume there is a method that > accepts dataset w/o knowing whether select list is specified or not > > def foo(dataset); dataset.select_more(:a) end > > Sequel 3.47 > > ------------------------------------------------------------------------------------------------- > jruby-1.7.4 :001 > def foo(dataset); dataset.select_more(:a) end > => nil > jruby-1.7.4 :002 > foo(DB[:table]) > => #<Sequel::JDBC::Dataset: "SELECT [A] FROM [TABLE]"> > > ------------------------------------------------------------------------------------------------- > Sequel 4.1,1 > jruby-1.7.4 :001 > def foo(dataset); dataset.select_more(:a) end > => nil > jruby-1.7.4 :002 > foo(DB[:table]) > => #<Sequel::JDBC::Dataset: "SELECT **,* [A] FROM [TABLE]"> > > ------------------------------------------------------------------------------------------------- > > As we see here wildcard is added by 4.1.1 version which causes some > problems for us. One of them is column name collisions when several tables > are joined. Another one having * will return more data then needed > increasing latency. > > I wonder if there is a clean way of configuring select_more behavior? > > P.S. Looks like "legacy" select_more was quite handy :) > > Consider the statement "Let's assume there is a method that accepts dataset w/o knowing whether select list is specified or not". The truth is, there is always a select list specified. If you don't manually specify it, the automatically specified one is '*' (SELECT with no expressions is not valid SQL). Having a method named select_more that actually selects less in certain cases is a design flaw.
That being said, if you want the old behavior, just add a new dataset method (#select_at_least ?) or change the definition of Dataset#select_more (risky as that could break things). If you are running Sequel 3.48.0, there should have been deprecation warnings, but no behavior change. The behavior change didn't occur until Sequel 4.0.0. I realize this was a change that could break things, which is why the change was made in a major version. Unfortunately, if you refuse to break code to fix design flaws, you are likely to end up with a messy library. 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/groups/opt_out.
