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

[Alexander Hartmaier]

I've added an after insert method modifier which calls discard_changes
for those result classes where I always want this to happen.

--
Best regards, Alex


On Wed, 2011-02-09 at 11:21 +0100, Dagfinn Ilmari Mannsåker wrote:
> 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.
>


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*