[Dbix-class] Excluding columns from a query

[Darren Duncan]

Rob Kinyon wrote:
> On Fri, Feb 12, 2010 at 09:35, Nick Wellnhofer <wellnhofer at 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.  (And individual DBMSs can still buck the trend by 
supporting that even if the SQL standard doesn't, considering they all have 
their own extensions anyway and this one is backwards compatible.)  DBIx::Class 
should support it natively regardless of whether SQL does just because it is 
good design and keeps the interface more balanced, and there are reasonable use 
cases for it.  As for how that is implemented, well the process would be related 
to how DBIx::Class supports "select * from foo"; to know what result columns you 
will have, you consult metadata you have about the structure of foo, either that 
you already hold or you ask the DBMS.

-- Darren Duncan