Hi all, Sorry this is just a bump. I'm still somewhat confused, so if anyone could help explain (see below) that would much appreciated!
Thanks, Chris -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Sent: 09 July 2008 22:17 To: [email protected] Subject: Re: [magnolia-user] custom module updates Hi, So, I'm still a little confused I'm afraid. >>"Moving keeps the original uuid. Just copy it or create a new one instead." I understand this, though to me this seems irrelevant - hence why I think I don't really understand quite what's going on. So, I'll try to explain my current thoughts, in the hopes someone can point out where I'm going wrong. As explained, I have a development system, and a production system, completely out-of-sync - consider them to be completely different systems e.g. like your system may well be heavily customised, but you still expect that when magnolia officially release a new module (from their development system), you can install it without problems. So I developed a new module in my development system, and when it came to installing it on the production system there was a uuid collision with another node. This node has absolutely no connection to the new module, it just so happens that it's uuid is the same as one of the files I'm trying to bootstrap from the new module. In the previous post, I referred to the DMSVersionModuleHandler: > Is this just hoping that there won't already be a node with a matching uuid And you stated that "there is no valid reason for this to happen" I guess this sums up my confusion really. Why is there no valid reason for it to happen, when I have encountered uuid collision from completely unrelated customisations. If you could explain this, then I think that would help me a great deal in understanding! Thanks, Chris //////////////////// Further details about what I want, and my thoughts/confusions about module version handlers: I want to code my ModuleVersionHandler such that it will bootstrap the new files that are specified. I want to be able to say that if one of the files for bootstrapping already exists, then it should overwrite it - i.e. an UPDATE (maybe I've completely changed one of the dialog definitions in my module for example) BUT, I do not want to overwrite a node that happens to have the same uuid, but is infact completely unrelated to the new files that are being bootstrapped. Repeating myself from a previous post (this is still indicative of my probably incorrecty thoughts): So my confusion is how should I deal with this? As I previously described, I want that if an updated config file is included in a module, it should replace the previously bootstrapped file. Previously you suggested using an importUUIDBehavior of IMPORT_UUID_COLLISION_REPLACE_EXISTING to achieve this. However in this instance, it would have deleted something completely unrelated from the config repository, and would have left the system in an inconsistent state. If it is the first time a file is included for bootstrapping in the module, obviously you know that you won't need to upgrade/overwrite from a previous version, so I guess there is some 'on uuid collision, generate new uuid' importUUIDBehaviour. But what happens when a new version of the module is released with an update to the config file which should be bootstrapped (and overwrite the previous config)? The uuid's will be out of sync now surely? -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Sent: 07 July 2008 03:51 To: [email protected] Subject: Re: [magnolia-user] custom module updates On Jul 7, 2008, at 3:20 AM, Allan, CJ (Chris) wrote: > Hi, > > Thanks very much for the reply. I have managed to get a working > ModuleVersionHandler. > > However, I'm still slightly confused. In my development environment > (which is Completely out of sync with the production environment) > the update all went fine. However, when I tried to install it in the > production environment I got the following error: > > Could not perform installation: Error importing > config.modules.diamond.dialogs.diamond.siblingPages: a node with > uuid 64a29663-997e-4eb6-9d1f-16632185d066 already exists! > > Performing a query against this uuid it returned: /modules/ > templating/dialogs/paragraphList > (this is a custom dialog definition created a while back - it is not > encapsulated within any module, merely added manually to the config > repository). This most likely is happening because you moved that node to your own module before exporting it. Moving keeps the original uuid. Just copy it or create a new one instead. > Also, looking at DMSModuleVersionHandler, it doesn't use any > importUUIDBehaviour. Is this just hoping that there won't already be > a node with a matching uuid, and leaving the problem for the user to > deal with if their is? Except there is no valid reason for this to happen. We changed this in 3.5 to avoid ghost problems: sometimes, by accident, we also had moved nodes around before exporting them in a new module for instance. What then happened is that the original node suddenly disappeared without warning from their original location, while what we really wanted was to keep both. Blowing on uuid conflicts is the safest way of avoiding these problems and forces the module developer to deal with them properly. -g ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/ ---------------------------------------------------------------- <DIV><FONT size="1" color="gray">This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom </FONT></DIV> ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/ ---------------------------------------------------------------- <DIV><FONT size="1" color="gray">This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom </FONT></DIV> ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/ ----------------------------------------------------------------
