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

Bengt Kleberg bengt.kleberg@REDACTED
Tue Nov 22 08:24:11 CET 2011


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
>         
> 
> 




More information about the erlang-questions mailing list