[Dbix-class] Excluding columns from a query

[Mike South]

On Fri, Feb 12, 2010 at 9:06 PM, Darren Duncan <darren at darrenduncan.net>wro=
te:

> 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=3DXY+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=3D> 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 lev=
el
> 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 shou=
ld
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100214/0b6=
9f3bd/attachment.htm