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

Barco You barcojie@REDACTED
Tue Nov 22 08:49:47 CET 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111122/b8775d64/attachment.htm>


More information about the erlang-questions mailing list