FW: [Dbix-class] Filtering module

Todd Rinaldo toddr at null.net
Wed Oct 22 15:26:45 BST 2008


> -----Original Message-----
> From: me at jackal.in [mailto:me at jackal.in]
> Sent: Tuesday, October 21, 2008 6:12 AM
> To: dbix-class at lists.scsys.co.uk
> Subject: [Dbix-class] Filtering module
>
>
> Hello,
>
> This is proposal for a filtering component, similar to
> DBIx::Class::InflateColumn
> It can -modify- columns transparently. When you read column - it inflates,
>
> when you write - deflates.
> On creating a new column, whole cycle passed - deflating for DB and
> inflating
> for usage.
> Module can handle scalars, because of it's destination - to modify data.
>
> Module can works together with InflateColumn:
> __PACKAGE__->modify_column('passw', ...);
> __PACKAGE__->inflate_column('passw', ...);
>
> In that case, when you read - it inflates into object by InflateColumn,
> then
> object will be modified by ModifyColumn. When wou write - there's reverse
> process.
> Kind regards, Eugeny.

I'm not sure if this was Eugeny's intention, but I read it as a
proposal to make a mode where inflate/default is used, regardless of
how you access the data via DBIC.

I too would like to see inflate be a little more transparent. I
haven't had to deal with it in a month or so, but I know that in some
DBIC calls, you get the raw value of the column and in others, you get
the inflated value. Vice-versa on the write. It's my humble opinion
that if someone sets up an inflate/deflate on a column, that should be
the interface. This has bitten us a couple of times, mostly with
DateTime objects where we made the assumption that get_column (I
think) would give us an inflated value, but instead gives us the raw
value.

Todd



More information about the DBIx-Class mailing list