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

[Christopher H. Laco]

>>> 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?

[mst]

>> 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
experience):

$obj->col('1-2-2007')

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.
>=20
> 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...
>=20

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...
$obj->datefield('1-2-2007');

## DateTime
ref $-obj->datefield


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

If I did:

$obj->datefield('01022007')

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...

-=3DChris

-------------- 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