[erlang-questions] code_change for gen_fsm: how to actually handle a state change
lenartlad@REDACTED
lenartlad@REDACTED
Tue Nov 22 09:33:46 CET 2011
Hello.
But code_change is the ONLY place aware of the OLD internal record
representation (i.e. a tuple). And you can't use record syntax
because at the time code_change is invoked, #state{} already
represents the NEW record:
* OLD is {state, I1, I2}
* NEW is {state, I1, I2 ,NEWField}
Compiler simply replaces all occurrences of #state{} with the NEW
tuple (because you're running the updating version of your module
with added field).
Updating code_change is simply a part of updating your module when
you modify state of your processes.
Ladislav Lenart
Od: "Barco You" <barcojie@REDACTED>
> So, that's to say we have to manually change the
> code_change callback
> whenever we update the state record?
> It seems to disobey the spirit of simple
> maintenance by taking the
> advantage of erlang record.
>
>
> Barco
>
> On Tue, Nov 22, 2011 at 3:40 PM, Bengt Kleberg
> <bengt.kleberg@REDACTED>wrote:
>
> >
> > Is it correct to say that the old definition of
> > #state{} is
> > > -record(state, {item1, item2}).
> > and that the new is
> > -record(state, {item1, item2, newfield}).
> >
> > I think you will find it difficult to get both
> > these records to work in
> > > the same file at the same time (during code
> > change).
> > >
> >
> > bengt
> >
> > On Tue, 2011-11-22 at 08:27 +0100, Barco You
> > wrote:
> > > > But I don't think it's much different from
> > > directly matching the
> > > > > record itself as shown by my previous mail.
> > >
> > >
> > >
> > >
> > > Barco
> > >
> > > On Tue, Nov 22, 2011 at 3:24 PM, Bengt Kleberg
> > > <bengt.kleberg@REDACTED> wrote:
> > > The old record is a tuple. Like this:
> > >
> > > code_change(_Old_version, State_name,
> > > {state, Item1, Item2},
> > > > > _Extra ) ->
> > > {ok, State_name,
> > > Data#state{item1=Item1,
> > > item2=Item2,
> > > > > newfield=something}.
> > >
> > >
> > > bengt
> > >
> > > On Tue, 2011-11-22 at 07:52 +0100,
> > > Barco You wrote:
> > > > > > What you mean is like this?
> > > >
> > > >
> > > > code_change(_OldVer, Statename, Data
> > > > = #state{}, _Extra) ->
> > > > > > > {ok, Statename, Data#state{
> > > > newfield = Something}.
> > > > > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Nov 22, 2011 at 2:38 PM,
> > > > Bengt Kleberg
> > > > > > > <bengt.kleberg@REDACTED> wrote:
> > > > Greetings,
> > > >
> > > > The way it is done in our
> > > > code (lots of it) is to
> > > > > > match the
> > > > old record
> > > > as a tuple.
> > > >
> > > >
> > > > bengt
> > > >
> > > > On Mon, 2011-11-21 at 16:51
> > > > +0100, Daniel Dormont
> > > > > > wrote:
> > > > > Hello all,
> > > > >
> > > > > I have a gen_fsm module
> > > > > and would like to take
> > > > > > > advantage of
> > > > hot code
> > > > > deploy. The module uses a
> > > > > record (called "state")
> > > > > > > and the
> > > > new version
> > > > > of the module includes
> > > > > some new fields in the
> > > > > > > record. What
> > > > is a nice
> > > > > clean way to code the
> > > > > my_module:code_change
> > > > > > > function to deal
> > > > with
> > > > > this? Are there any good
> > > > > examples out there on the
> > > > > > > web?
> > > > >
> > > > > Note: for my purposes it
> > > > > would be sufficient to
> > > > > > > detect that
> > > > the state
> > > > > record is out of date, and
> > > > > terminate cleanly. BUT
> > > > > > > the
> > > > correct
> > > > > functionality of the
> > > > > terminate/3 function in my
> > > > > > > module
> > > > depends on the
> > > > > state data, and I would
> > > > > need it to complete
> > > > > > > cleanly and not
> > > > crash in
> > > > > this instance because
> > > > > there are other processes
> > > > > > > that depend
> > > > on this
> > > > > one and need to be
> > > > > notified properly of its
> > > > > exit.
> > > > > > > The issue
> > > > is that
> > > > > the state itself contains
> > > > > the data of which
> > > > > > > processes those
> > > > are.
> > > > >
> > > > > What's the best approach
> > > > > here?
> > > > > > > > >
> > > > > thanks,
> > > > > Dan
> > > > > _______________________________________________
> > > > > > > > > > > > > > erlang-questions
> > > > > > > > > mailing
> > > > > > > > > > > > > > list
> > > > > > > > > erlang-questions@REDACTED
> > > > > > > > > > > > > > > > > >
> > > http://erlang.org/mailman/listinfo/erlang-questions
> > > > > >
> > > > _______________________________________________
> > > > > > > > > > > erlang-questions
> > > > > > > mailing
> > > > > > > > > > > list
> > > > > > > erlang-questions@REDACTED
> > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-questions
> > > > > > > > > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > > > erlang-questions mailing list
> > > erlang-questions@REDACTED
> > > http://erlang.org/mailman/listinfo/erlang-questions
> > > > >
> > >
> > >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> > >
>
--
Staňte se fanoušky portálu VOLNÝ.cz na Facebooku a můžete si zahrát
o vstupenky na konopný veletrh a vaporizér
http://web.volny.cz/data/click.php?id=1297
More information about the erlang-questions
mailing list