RE: force re-retrieve from database

[prev] [thread] [next] [Date index for 2005/06/14]

I have a method to do this:

sub _attribute_delete_all {
    my $self =3D shift;

    my %primary =3D map { $_=3D>1 } $self->primary_column;
    my @columns =3D $self->all_columns;
    for (@columns) {
      $self->_attribute_delete($_) if (!$primary{$_});
}


Regards,

John Zhuang Li

> -----Original Message-----
> From: Hartmaier Alexander [mailto:Alexander.Hartmaier@xxxxxxxxx.xx]
> Sent: Tuesday, June 14, 2005 7:48 AM
> To: cdbi-talk@xxxxxx.xxxxx.xxx
> Subject: Re: force re-retrieve from database
>=20
> Ok I like the idea.
> I looked in Class/DBI.pm for the update method to figure out how to =
delete
> attributes from an object but didn't find what I wanted.
> These lines seem to do what I want but I don't want to use internals =
that
> might change in a new version:
>=20
>=20
> $self->call_trigger('after_update', discard_columns =3D> =
\@changed_cols);
>=20
>         # delete columns that changed (in case adding to DB modifies =
them
> again)
>         $self->_attribute_delete(@changed_cols);
>         delete $self->{__Changed};
>=20
> What does the first line do?
> Do I have to take care of '$self->{__Changed}' to not break something =
else?
>=20
> I THINK that '$self->_attribute_delete(('mycolname'));' would be =
enough but
> I want an official ACK from the cdbi developers/maintainers...
>=20
> -Alex
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Charles Bailey [mailto:bailey@xxxxxx.xxxxx.xxx]
> > Gesendet: Dienstag, 14. Juni 2005 15:48
> > An: Hartmaier Alexander; cdbi-talk@xxxxxx.xxxxx.xxx
> > Betreff: Re: force re-retrieve from database
> >
> > --On June 14, 2005 10:44:33 AM +0200 Hartmaier Alexander
> > <Alexander.Hartmaier@xxxxxxxxx.xx> wrote:
> >
> > >> If you're trying to update the object in hand, you should be able =
to
> > >> just
> > >> undef it and then retrieve it again.  If there are other copies =
in
> > scope
> > >> elsewhere, you may need to disable the object index or explicitly
> > remove
> > >> the object.
> > >>
> > >> Alternately, you could write an after_set_foo trigger that =
explicitly
> > >> refresh the columns in question.  I'm a little surprised that =
this
> > >> didn't
> > >> happen automagically, since CDBI clears out columns after writing =
to
> > the
> > >> DB
> > >> to account for this case.  Are the columns part of the object's
> > primary
> > >> key?
> > >>
> > >> --
> > >> Regards,
> > >> Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
> > >> Newman Center at the University of Pennsylvania
> > >
> > > I don't update the datetime fields and therefore they don't get
> > > automagically dropped and fetched from the db. They get updated by
> > oracle
> > > triggers.
> > > I would be ok for me to tell cdbi to drop those fields too.
> > > Maybe a '$obj->reretrieve(@fields)' method would be useful. If to
> > > fieldnames are given the whole object is fetched again from the db =
or
> > > only the fields given.
> >
> > OK, I understand; I hadn't been thinking broadly enough.  I'd =
recomment
> > an
> > after_update trigger (perhaps in your base class), that deletes =
these
> > attributes from the object.  In essence, your class knows about some
> > behind-the-scenes activity in your database that vanilla CDBI =
doesn't,
> > so
> > it should give CDBI a behind-the-scenes hint that'll allow the user =
to
> > see
> > the correct values without any extra work.
> >
> > --
> > Regards,
> > Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
> > Newman Center at the University of Pennsylvania