On Fri, Feb 12, 2010 at 9:06 PM, Darren Duncan <dar...@darrenduncan.net>wrote:
> Rob Kinyon wrote: > >> On Fri, Feb 12, 2010 at 09:35, Nick Wellnhofer <wellnho...@aevum.de> >> wrote: >> >>> On 12.02.2010 15:17, Rob Kinyon wrote: >>> >>>> What is the *USE CASE* that is leading you to think that excluding >>>> columns from a ->search is a good idea? >>>> >>> It's simply an optimization. I have a table with a text column that can >>> contain tens of KB of data per row. I also have some queries that don't >>> need that column, so I'd like to avoid unnecessarily fetching all that >>> content from the DB. >>> >> >> Ah. Now, had you said this at the beginning, you would have received >> an answer yesterday. http://www.google.com/?q=XY+Problem >> >> There is currently no clean way to do this. The best way I can think >> of would be something like: >> 1) Don't specify it as a column in your resultsource. >> 2) when you need it, add it in the columns=> attribute and use >> get_column('x') >> >> It's not very simple right now. Ideally, there would be a >> "fetch_lazily" column attribute. Patches welcome. :) >> > > Logically, being able to specify directly what you don't want is a good > idea simply for means of completeness and balance. > > In any situation where you can specify a condition, it is reasonable to be > able to specify the complementary or opposite condition with the same level > of verbosity. > > With Perl's "grep" or SQL's "where"/"having", specifying a complement is as > simple as prepending "not" to an otherwise identical condition. Both of > these operations are normally picking a subset of a given set, and it is > reasonable to request the complementary subset. > > And so, if you can say "select <column-name-list> from foo" then one should > also be able to say "select all but <column-name-list> from foo". Arguing > that this shouldn't be the case is like arguing that "not" or "!" shouldn't > be supported. > > This is something simple that SQL should support natively, and if it > doesn't then that's a failing of SQL. hear, hear. SQL doesn't have it afaik--its failure to have it is exactly that. I have wanted it many, many times. From a command line client, wanting everything but that one column that blows out the display, etc. I think the fact that the failure to have this is so widespread comes from SQL's failure to have it. I am not a real computer scientist--maybe there is some good reason for this to be unavailable in SQL? But as far as use cases go, I think this would obviously be useful. A column with a large amount of data, a column with sensitive data, a column that should be read only, any set of columns that are always going to be there but never going to be wanted--you can code it "all but X" and if 'all' changes your code is still pulling the correct set. In other words, I think it would be in the category of "obviously useful", and maybe something that hasn't been asked for a lot because it's also in the category of "inexplicably missing" from SQL, and people have just become accustomed to coding around its absence. mike
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk