[erlang-questions] code_change for gen_fsm: how to actually handle a state change

lenartlad <>
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" <>
> 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
> <>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
> > > <> 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
> > >         > > >         > <> 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
> > >         >         > > >         >         > 
> > >         >         > > >         >         > > > >         >         > > >         >         >
> > >         http://erlang.org/mailman/listinfo/erlang-questions
> > >         > >         >
> > >         >         _______________________________________________
> > >         >         > > >         >         > >         >         erlang-questions
> > >         >         > >         >         mailing
> > >         >         > >         >         > > >         >         list
> > >         >         > >         >         
> > >         >         > >         >         > > >         >         http://erlang.org/mailman/listinfo/erlang-questions
> > >         >         > > >         >         > >         >
> > >         >
> > >         >
> > >
> > >         _______________________________________________
> > >         > >         erlang-questions mailing list
> > >         
> > >         http://erlang.org/mailman/listinfo/erlang-questions
> > >         > >
> > >
> > >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > 
> > 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