[Dbix-class] Re: Populating Instance With Column's Defaults

[Peter Rabbitson]

Skye Shaw wrote:
> 2011/2/9 Peter Rabbitson <rabbit+dbic at rabbit.us>:
>> Dagfinn Ilmari Mannsåker wrote:
>>> Peter Rabbitson <rabbit+dbic at rabbit.us> writes:
>>>> Skye Shaw wrote:
>>>>> Hello,
>>>>>
>>>>> Is it possible to have DBIC populate a newly created instance with the
>>>>> underlying table's defaults when a value isn't provided?
>>>> The reason is that having every insert be followed by a select is...
>>>> how shall I put it, insane?!
>>> We already use INSERT ... RETURNING ... to get the ID if the DB supports
>>> it, couldn't that be extended to get all the columns that weren't
>>> specified in the ->new/->create call?
>> Right, and this will introduce an insane amount of broken code, since your
>> dev will work fine on a Pg version that supports IR, and will all of a
>> sudden stop working entirely in production on a different db or on an
>> older version of Pg, since now all the data you expected to be there is
>> suddenly UNDEF.
> 
> 
> I do not know DBIx internals but, on the surface, DBI does provide the
> column_info method. Sure underlying driver support for this method can
> vary but are there really any DBs that DBIx currently supports that
> don't provide a way to query table metadata?
> 
> Loading the metadata once, when the class is loaded, is all that's needed.
> 

I am now confused - so you *do* want to get the default value automatically
from the db, but want to do it for simple values only? If so - then yes this
is somewhat doable, since the database introspection has gotten better (in
the sense that we now can deal with 50% of the corner cases compared to 5%
when default_value came to be). I can see the possibility of a DBIC extension
which:

* defines and maintains a new attribute for dbic-side defaults (which value
is taken at the same time when DBIx::Class::DynamicDefault would fire)
* if attribute value is not present, attempts to populate this attribute
automatically from the database, and sets it to undef if the retrieval
somehow failed (or if the default is non-trivial e.g. a function)

With that said - patches are certainly welcome, as long as we do not try to
give more meaning to the (badly named, but nevertheless) pre-existing
default_value

Cheers!