fREW Schmidt wrote:
Gah, I should have read this thread sooner! I am actually working on
adding such a feature to DBIC. Getting it to work is quite easy.
Getting the right semantics is hard. For instance, we've discussed
this on IRC and really there are two options:
1. Only have the remove-columns affect the default select, since
having it affect an explicit columns list is a little silly.
2. Having it affect the *current* select list; the use-case for this
would be if you had an explicit columns list in previous search
(or a predefined search more likely) and you wanted to take away a
column from that.
I'm personally in favor of the former, mostly because it's the simplest
to explain, test, and implement, and really all this is is a shortcut
anyway.
Honestly I've implemented this twice now, both ways, but we need to nail
down the semantics. Furthermore, I feel like implementing remove-select
and remove-as is needlessly complex. If someone provides a select/as
just blow it away with columns.
What do you guys think?
I consider #2 to be a more complete solution, and #1 to be a trivial case of #2,
albeit the most important one.
For syntax, I would just support remove-columns in exactly the same way as the
select-list, or integrate those 2 things into a single query part, which
effectively they are.
The most elegant solution I see, conceptually at least, is to treat everything
except the remove-columns as if it were a plain subquery/view/table and then the
semantics are to return everything that does by default except what
remove-columns lists.
That is, exactly the same semantics as a normal select-columns except you return
the complementary column set.
And so, when you are doing query chaining such as a DBIC feature, the result of
each prior item in the chain is effectively a source subquery/view/table of the
next part, in which case the semantics for the new feature should be obvious.
More broadly speaking, one should be able conceivably to take any monolithic
SELECT and break it down into a chain of distinct operations, eg the join and
where and group and select-list (projection) would each be a new query in the
chain based off the result of the previous operation; the order that the parts
are in the chain can be variable to some extent, those operations being
logically associative (except when duplicates or nulls are involved).
That's how I see this anyway.
-- 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/dbix-class@lists.scsys.co.uk
