Rob Kinyon wrote:
On Fri, Feb 12, 2010 at 09:35, Nick Wellnhofer <[email protected]> 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
_______________________________________________
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/[email protected]
