[Dbix-class] Excluding columns from a query

[Darren Duncan]

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