And then a new process would be restarted by the supervisor with new version code?<div>If in that way, how do you recover the state data?</div><div><br></div><div>Barco<br><br><div class="gmail_quote">On Tue, Nov 22, 2011 at 10:46 PM, Daniel Dormont <span dir="ltr"><<a href="mailto:dan@greywallsoftware.com">dan@greywallsoftware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks, that makes sense.<br>
<br>
Here's another crazy idea, that I don't imagine is possible: can I<br>
give code_change some kind of return value that says to the system "go<br>
ahead and terminate this process, but call terminate/3 with the _old_<br>
version of the code"? I know it sounds weird, but that would also be a<br>
solution here.<br>
<br>
dan<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 22, 2011 at 5:35 AM, Richard Carlsson<br>
<<a href="mailto:carlsson.richard@gmail.com">carlsson.richard@gmail.com</a>> wrote:<br>
> On 11/22/2011 08:40 AM, Bengt Kleberg wrote:<br>
>><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>
><br>
><br>
> Possible solution: let code_change call a separate module that transforms<br>
> the old definition to an intermediate format that the gen_fsm module can use<br>
> to initialize the new state. That way, the different record declarations are<br>
> never present in the same module.<br>
><br>
> code_change(#state{}=State) -><br>
>    State;  % already the new state<br>
> code_change(OldState) -><br>
>    init_state(state_converter:old_to_proplist(OldState)).<br>
><br>
> init_state([{foo, Foo} | Ps], State) -><br>
>    init_state(Ps, State#state{foo=Foo});<br>
> ...<br>
> init_state([], State) -><br>
>    State.<br>
><br>
> A more quick-and-dirty solution is to re-tag the old state so you can use it<br>
> with a different state declaration:<br>
><br>
> -record(old_state, {item1, item2}).<br>
> -record(state, {item1, item2, newfield}).<br>
><br>
> code_change(#state{}=State) -><br>
>    State;  % already the new state<br>
> code_change(OldState) -><br>
>    update_state(setelement(1, State, 'old_state'), #state{}).<br>
><br>
> update_state(OldState, State) -><br>
>    State#state{item1 = OldState#old_state.item1,<br>
>                item2 = OldState#old_state.item2,<br>
>                newfield = 42}.<br>
><br>
><br>
>    /Richard<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>
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>