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

[Dagfinn Ilmari Mannsåker]

Peter Rabbitson <rabbit+dbic at rabbit.us> writes:

> 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 answer appears to be no. If so, what's the reason for this behavior?
>>> 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 didn't mean to imply behaving differentely under different database
drivers, just that the "insane" overhead of an extra select can be
avoided for some of them.  Sorry about the ambiguous wording.

>> [...]
>>> Note that frew would be very happy if you contribute an "auto-retrieve
>>> defaults" component to DBIx::Class::Helpers
>>
>> Hm, tempting... Just have to make sure not to interfere with DBIC's own
>> use of RETURNING.
>
> The only way to go is with an optional component which provides you the
> defaults *regardless* of what the db capabilities are (and does use IR when
> it is supported by the storage for fastiness). As far as compatibility -
> this is not a concern, if such a component materializes it is trivial to
> provide the necessary hooks (if any are needed at all).

Exactly.

-- 
ilmari
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen