Please take a look at BackupImportController::private List<Users> readUserList(line 714) The first loop starting at line 728 is removing duplicated "deleted" node
complicated part at line 749 (marked as HACK in comments) did the following: if this is the backup of fresh version (2.1) then do nothing If it is old backup and it has address and sipdata fields merged into user fields then parse it extensively) I create converters to support old format. All newly added and nullable fields are marked as "required='false'" I hope I don't miss any significant parts. In case of future refactoring we need to add "name" attribute to @Element annotation to ensure import/export is not changed. On Sun, Sep 9, 2012 at 1:11 AM, [email protected] <[email protected] > wrote: > Ok, > > thanks for taking that serious :) > The issue is that we have now two attributes: > title_id and salutations_id that do represent the same. > > I have been reviewing part of the BackupImportController, it is just > very clean now compared to before. > I think you covered all the tricky parts and refactored into the new > mechanism. > > But how does it deal with attribute name changes, is there a way in > the UserConverter for example where we could define an alternative > mapping so that it gets backward compatible? > > Thanks! > Sebastian > > 2012/9/8 Maxim Solodovnik <[email protected]>: > > I did test old backups while refactoring import. > > I'll double check my latest changes. > > > > I have added > > @Element(name="title_id", data=true, required=false) > > so exported and imported element name will be "title_id" (backward > > compatible) > > > > I will test if new Salutations field works. > > I did change this code since it was not compilable (Eclipse reported > > setSalutation(int) is illegal). > > > > > > On Sat, Sep 8, 2012 at 11:07 PM, [email protected] > > <[email protected]> wrote: > >> > >> Sorry I did not know that new implementation. > >> What is the inted way for the new implementation to handle backward > >> compatibility. > >> I mean: > >> I have now changed the attribute title_id to saluation_id. Does that > >> mean that all old backup ZIPs will not work anymore because there are > >> different attribute name used in that Users object? > >> > >> There are a number of such fields that, from my point of view the goal > >> of the importer was always to be able to import any old backup ZIPs. > >> That means that there could be schema changes from one version to the > >> next. > >> That also means that whole tables, attribute names or attribute types > >> may change from one version to the next. That is actually the reason > >> for having that in a database/schema independent XML format. > >> > >> How can we make sure now that those olde backups still will work? > >> > >> Sebastian > >> > >> 2012/9/8 [email protected] <[email protected]> > >> > > >> > Okay, > >> > > >> > but what have you done with your commit now? > >> > There are now two attributes in the Users table: > >> > title_id > >> > and salutation_id > >> > > >> > and two attributes: > >> > salutation_id > >> > and > >> > salutations > >> > > >> > I have implemented it in that way that there are two attributes, while > >> > "saluations" is read only (insertable = false, updatable = false). > >> > I have kept the salutations_id because I did not want to modify too > much > >> > of the code in the OpenLaszlo client for now. But what you have done > now > >> > simply does not work. Why? > >> > > >> > Sebastian > >> > > >> > > >> > > >> > 2012/9/8 Maxim Solodovnik <[email protected]> > >> >> > >> >> Hello Sebastian, > >> >> > >> >> Does > >> >> UserImport.java > >> >> Export.java > >> >> > >> >> Are still used in our code? > >> >> If yes I believe it need to be refactored like BackupImportController > >> >> line 288 > >> >> > >> >> I believe the code doing similar things should be in 1 place only. > >> >> > >> >> -- > >> >> WBR > >> >> Maxim aka solomax > >> > > >> > > >> > > >> > > >> > -- > >> > Sebastian Wagner > >> > https://twitter.com/#!/dead_lock > >> > http://www.webbase-design.de > >> > http://www.wagner-sebastian.com > >> > [email protected] > >> > >> > >> > >> > >> -- > >> Sebastian Wagner > >> https://twitter.com/#!/dead_lock > >> http://www.webbase-design.de > >> http://www.wagner-sebastian.com > >> [email protected] > > > > > > > > > > -- > > WBR > > Maxim aka solomax > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
