From: "fREW Schmidt" <fri...@gmail.com>
On Thu, Feb 18, 2010 at 7:02 AM, BUCHMULLER Norbert
<norbi.li...@nix.hu>wrote:
On Wed, 17 Feb 2010 09:19:44 -0600 fREW Schmidt wrote:
> 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'd vote for #2 as it would make possible things like that (a variant of
the use-case you mentioned):
$rs->method_that_adds_a_calculated_column->search(
...
{
remove_columns => ['big_text_column'],
}
); # and still have the calculated column (added via "+columns")
Also this behaviour is the less surprising: with #1 the behaviour of
'remove_columns' (or '-columns' or whatever it will be called)
would depend on whether a given column comes from the result source or
from a previous search() call.
norbi
ok, I've heard from I think 4 people regarding this now and everyone is in
favor of #2. I'll implement it soon (within a week hopefully.)
--
fREW Schmidt
http://blog.afoolishmanifesto.com
Would it be possible to specify columns from joined tables like in the line
below?
remove_columns => ['big_text_column',
'another_table.another_big_column'],
It would be great!
Octavian
_______________________________________________
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