<div>So, that's to say we have to manually change the code_change callback whenever we update the state record?</div><div>It seems to disobey the spirit of simple maintenance by taking the advantage of erlang record.</div>
<div><br></div><div><br></div><div>Barco</div><div><br><div class="gmail_quote">On Tue, Nov 22, 2011 at 3:40 PM, Bengt Kleberg <span dir="ltr"><<a href="mailto:bengt.kleberg@ericsson.com">bengt.kleberg@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Is it correct to say that the old definition of #state{} is<br>
-record(state, {item1, item2}).<br>
and that the new is<br>
-record(state, {item1, item2, newfield}).<br>
<br>
I think you will find it difficult to get both these records to work in<br>
the same file at the same time (during code change).<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
bengt<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, 2011-11-22 at 08:27 +0100, Barco You wrote:<br>
> But I don't think it's much different from directly matching the<br>
> record itself as shown by my previous mail.<br>
><br>
><br>
><br>
><br>
> Barco<br>
><br>
> On Tue, Nov 22, 2011 at 3:24 PM, Bengt Kleberg<br>
> <<a href="mailto:bengt.kleberg@ericsson.com">bengt.kleberg@ericsson.com</a>> wrote:<br>
>         The old record is a tuple. Like this:<br>
><br>
>         code_change(_Old_version, State_name, {state, Item1, Item2},<br>
>         _Extra ) -><br>
>                {ok, State_name, Data#state{item1=Item1, item2=Item2,<br>
>         newfield=something}.<br>
><br>
><br>
>         bengt<br>
><br>
>         On Tue, 2011-11-22 at 07:52 +0100, Barco You wrote:<br>
>         > What you mean is like this?<br>
>         ><br>
>         ><br>
>         > code_change(_OldVer, Statename, Data = #state{}, _Extra) -><br>
>         >          {ok, Statename, Data#state{ newfield = Something}.<br>
>         ><br>
>         ><br>
>         ><br>
>         ><br>
>         ><br>
>         > On Tue, Nov 22, 2011 at 2:38 PM, Bengt Kleberg<br>
>         > <<a href="mailto:bengt.kleberg@ericsson.com">bengt.kleberg@ericsson.com</a>> wrote:<br>
>         >         Greetings,<br>
>         ><br>
>         >         The way it is done in our code (lots of it) is to<br>
>         match the<br>
>         >         old record<br>
>         >         as a tuple.<br>
>         ><br>
>         ><br>
>         >         bengt<br>
>         ><br>
>         >         On Mon, 2011-11-21 at 16:51 +0100, Daniel Dormont<br>
>         wrote:<br>
>         >         > Hello all,<br>
>         >         ><br>
>         >         > I have a gen_fsm module and would like to take<br>
>         advantage of<br>
>         >         hot code<br>
>         >         > deploy. The module uses a record (called "state")<br>
>         and the<br>
>         >         new version<br>
>         >         > of the module includes some new fields in the<br>
>         record. What<br>
>         >         is a nice<br>
>         >         > clean way to code the my_module:code_change<br>
>         function to deal<br>
>         >         with<br>
>         >         > this? Are there any good examples out there on the<br>
>         web?<br>
>         >         ><br>
>         >         > Note: for my purposes it would be sufficient to<br>
>         detect that<br>
>         >         the state<br>
>         >         > record is out of date, and terminate cleanly. BUT<br>
>         the<br>
>         >         correct<br>
>         >         > functionality of the terminate/3 function in my<br>
>         module<br>
>         >         depends on the<br>
>         >         > state data, and I would need it to complete<br>
>         cleanly and not<br>
>         >         crash in<br>
>         >         > this instance because there are other processes<br>
>         that depend<br>
>         >         on this<br>
>         >         > one and need to be notified properly of its exit.<br>
>         The issue<br>
>         >         is that<br>
>         >         > the state itself contains the data of which<br>
>         processes those<br>
>         >         are.<br>
>         >         ><br>
>         >         > What's the best approach here?<br>
>         >         ><br>
>         >         > thanks,<br>
>         >         > Dan<br>
>         >         > _______________________________________________<br>
>         >         > erlang-questions mailing list<br>
>         >         > <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>         >         ><br>
>         <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>         ><br>
>         >         _______________________________________________<br>
>         >         erlang-questions mailing list<br>
>         >         <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>         >         <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>         ><br>
>         ><br>
>         ><br>
><br>
>         _______________________________________________<br>
>         erlang-questions mailing list<br>
>         <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>         <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>