[Dbix-class] RFC: Inflating user-supplied values

Christopher H. Laco claco at chrislaco.com
Mon May 7 18:16:08 GMT 2007

>>> and while it is all working now (thanks Claco!) I have to admit I
>>> still find the behavior counter-intuitive at best.  I guess when I
>>> was just inflating DateTime objects it made more sense, since the
>>> inflated values were so much more complex than the representation
>>> that was stored in the database, but when I started using
>>> DBIx::Class::InflateColumn::Currency, it seemed odd to me that
>>> '$10.00' would be inflated to a Data::Currency object if it came from=

>>> the database, but not if it came from the user.  I've fixed this for
>>> my immediate need by writing an HTML::FormFu::Inflator subclass that
>>> parallels DBIx::Class::InflateColumn::Currency, but going forward I'd=

>>> like to avoid repeating so much code, so I've come up with an idea to=

>>> extend DBIx::Class::InflateColumn to allow user-provided values to be=

>>> inflated the same way that database values are.
>> Well, if you call $obj->inflated_field('$10.00');
>> then do $obj->inflated_field; the second call will return the inflated=

>> object.
>> I'm not sure I see what the problem you're trying to solve is?


>> Well, if you call $obj->inflated_field('$10.00');

The problem is, that will never work. I could be wrong, but whatever you
pass to inflated columns has to either be an inflated object, or a valid
value matching EXACTLY what the current DB supports.

In this case '$10.00' is neither a currency object, nor a valid value
for a db column of type float.

The same has always been true for DateTime fields (at least in my


will never work in database that don't grok that datetime format. But if
you pass in a DateTime object, all is well...

> The original problem I was having was a combination of
> DBIx::Class::FormFu and DBIx::Class::InflateColumn::Currency.  When a
> form was submitted that had dollar amounts in the inflated fields, the
> database would get updated with 0's in all the currency columns,
> DBIC_TRACE revealed that this was because the un-inflated values were
> being passed to the database and MySQL was setting those fields to 0
> since it considered the data it was getting to be non-numeric as it
> started with a '$'.  My attempts to locate the source of the problem
> (and the responses I got to my initial post) all suggested that only
> data coming from the database would be inflated and that if I wanted to=

> set it manually I needed to do $obj->inflated_field(
> Data::Currency->new( '$10.00' ) ).

And to my original post, Data::Currency->new( '$10.00' ) will never
work... Data::Currency->new( '10.00' ) would...

  Since you indicated this isn't the
> case, I built a minimal test case this morning and confirmed that
> indeed, this should just work, so I guess now I need to go back to
> trying to figure out why the wrong information is being passed to the
> database in the larger application.
> So it appears the RFC was actually an attempt to add functionality that=

> does indeed already exist, and now I get to go back to debugging...

what's the test case?
Is IC::DateTime doing special parsing of non inflated values into
inflated values before saving to a database?

## passing in a string...

## DateTime
ref $-obj->datefield

I expect the second line to work... but ONLY if the db groks '1-2-2007'

If I did:


I would not expect

$obj->update to work without error...not would I expect $obj->datefield
to return a correct DateTime object...

Again, unless I'm missing something, everything is working as
intended... '$10.00' is not a valid float value nor a currency
object...and $obj->inflated_column takes a direct db compatible value or
a pre inflated object...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070507/8081e546/signature.pgp

More information about the Dbix-class mailing list