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

Reply via email to