[Dbix-class] Re: Blessed objects as scalar values: what to do ?

BUCHMULLER Norbert norbi.lists at nix.hu
Thu Nov 6 16:26:51 GMT 2008


On Thu, 6 Nov 2008 16:08:12 +0100 "Dami Laurent (PJ)"
<laurent.dami at justice.ge.ch> wrote:

> That's a question of defensive programming.

Yes, though it blows up SQLA - either cleanly (I mean a proper error
message), or some other way. :-) OTOH if we let it pass back to the user
who has the responsibility to do whatever (s)he want to do with it before
(s)he passes it on to DBI (or to any other db engine API), then the user
has the freedom to use this freedom for good. Of course if the user does
not prepare for this case and simply passes it on to the db engine API,
it may cause more obscure errors..

> SQLA decides what to do on the basis of the 'refkind' of its arguments
> (is it a hashref, a scalarref, a plain scalar, etc.). If the argument
> is an object reference, what should be done ? My initial view was that
> this most probably an error from the client, so SQLA should complain.

In fact even some DBIC test cases pass DateTime objects to SQLA, assuming
that it will be stringified when appropriate.

> Then your proposal was to treat it exactly like a scalar, and pass it
> through to DBI and then to the DBD driver. As far as SQLA is concerned,
> this could be OK, but then there are chances that this would result in
> strange errors in DBI or DBD::*, that would be harder to understand.

Exactly.

> Therefore my proposal was to say : OK, let's treat objects like
> scalars, but only if they have a method to effectively transform
> themselves into a scalar. This makes it likely that such objects can
> indeed be inserted into databases.

And we should make it more robust, to not explode but die (with proper
error msg) if the object cannot be stringified.

> I don't know, maybe this view is too strong ... but on the other hand,
> do you have any real-world use cases where object references are passed
> to DBI ?

Well, maybe a bit contrived, but there may be cases when the default
date format ('2008-11-06T16:14:45') that DateTime produces on
stringification is not suitable for the db engine, or when a
'mini-ORM' (few dozen lines of code built on top of SQLA) wants to fix
the time zone of DateTime objects passed by the user (though this later
one is usually a sign of biiig problems in the background).

> If we really want more flexibility, maybe what could be done is to add
> a new option in the SQLA contructor SQL::Abstract->new(value_classes =>
> [qw/Foo::Bar, etc/]) In that scenario, object references would be
> accepted as scalar values if and only if they belong to one of the
> given classes (or descendants).

I like it. (In the list we may accept strings - to use with isa()
- and regexes - to use with ref() - , I suppose.)

norbi



More information about the DBIx-Class mailing list