<br><br>
<div><span class="gmail_quote">2008/7/17, Hakan Mattsson <<a href="mailto:hakan@erix.ericsson.se">hakan@erix.ericsson.se</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Thu, 17 Jul 2008, devdoer bird wrote:<br><br>db> 2008/7/17, Hakan Mattsson <<a href="mailto:hakan@erix.ericsson.se">hakan@erix.ericsson.se</a>>:<br>
db> ><br>db> > On Thu, 17 Jul 2008, devdoer bird wrote:<br>db> > db> My question is<br>db> > db> 1. while the upgrade is in in progress, is the user record I read<br>db> > db> either the version 1 or the version 2 ? That is I can't be sure<br>
db> > db> one user record's current version.<br>db> > db> 2. while the upgrade is in progress,will the modify  of the old user<br>db> > db> record be lost?<br>db> ><br>db> > It will differ per module and process. During the upgrade you may have<br>
db> > some processes that are using the old module and some are using the<br>db> > new module. If this is an issue, you need to perform a more advanced<br>db> > upgrade procedure that first suspends the processes, then loads the<br>
db> > new code and finally resumes the processes.<br>db><br>db> I can't understand. Won't one process read either version 1 or version 2?<br>db> Eg. there're 5 user records of version 1 intially, when I do<br>
db> transform_table,there may<br>db> be 3 user records of version 1,and 2 user records of version 2 if the<br>db> transform_table operation is not finished yet.<br><br>mnesia:transform_table/2 grabs a table lock. If you are using<br>
transactions you need to wait for the transform to complete before you<br>can access the table.<br><br>If you are performing dirty access during the mnesia:transform_table/2<br>operation, reading of some records will result in version 1 and others<br>
will result in version 2. Dirty updates may be overwritten by<br>mnesia:transform_table/2.<br><br>Then you have the issue of which version of your code that is<br>running. During the code upgrade, some processes will run version 1 of<br>
a module (using version 1 of the record definition) while others will<br>run version 2 of the module (using version 2 of the record definition).</blockquote>
<div> </div>
<div>Thanks a lot.I still has one question .If the transform_table grabs the table lock,then how  does the mnesia support the hot-upgrade table operation?</div>
<div>Because the transform table grabs table lock,the cocurrent write opertion will be blocked until the tranform_table is done.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">db> > db> 3. If the 1 and 2 are true,how can I  code two handle them?<br>db> > db> Shall I have to have two versions of process code to handle<br>
db> > db> this situation ,like:<br>db> > db> process_one_user(UserRecord)-><br>db> > db>    case of current_version(UserRecord) of<br>db> > db>         v1-> do something;<br>db> > db>         v2->do  something<br>
db> > db>      end<br>db> > db> end<br>db> ><br>db> > One way of getting better control of this, is to change the name<br>db> > of the record. Then it will be easy to test which "version" of<br>
db> > the record that you are using. See also mnesia:transform_table/4.<br>db><br>db> If I do so,many codes rely on the original record name will be<br>db> changed, and I have to code in  if-else style in many place .<br>
db> Am I right?<br><br>Yes. If the change affects too many modules, that approach is impractical.<br><br>An other way of handling it is to have wrapper functions for all<br>reading operations in Mnesia. If the wrapper detects a record with<br>
version 1 it could transform it into version 2.<br><br>/Håkan<br>---<br>Håkan Mattsson (uabhams)<br>Erlang/OTP, Ericsson</blockquote></div><br>