Has anyone played with it yet? I have made a couple of attempts that are unsatisfactory.
In my experiments it has successfully upgraded tables, table occurrences, relationships, and scripts.
It hasn't upgraded layouts and layout objects.
I haven't found links to documentation of the XML grammar yet, so I can't be sure that I'm generating the correct instructions in the patch file . In the video they tell us that we must create the patch file manually. They suggest that we use Save as XML copy or Save as DDR as a basis but then say that the output has to be modified to be used as a patch.
There are a couple of steps that they describe
Generate initial XML output using Save as XML Copy or Database Design Report
Modify XML output to generate a patch file
The most important change is that the root element for the patch file is FMUpgradeToolPatch
The second thing to note is that the upgrade tool XML structure is much closer to XML Copy format than DDR format.
In the video they also note that the patch file should only include the objects which have been added, removed, or modified. This seems sensible because it reduces the likelihood of errors.
(I did run a test that included everything and it produced the same output as the minimal patch but its probably not a good idea to do that. )
This means doing a diff to determine where the difference are
BUT generating the diff isn't as simple as running a diff.
The patch file needs to know what the whole object is, let's call that the XML framework, which will be common to both files, so a diff tool won't identify those lines as they haven't changed.
Diff tools will generate a LOT of false positives with UUIDs, timestamp changes and so on.
Even an XML aware diff tool will struggle with that. This means that the task of generating a patch requires careful manual editing.
I'm using the visual diff tools in NetBeans IDE, plus a splash of vim and other command line tools. I'd love to know what tools others are using to manage this job.
We played with it extensively during ETS but since there is no official documentation and more importantly, no DTD or grammar doc on the XML yet, we are not willing to risk using it for real. Being able to validate the diff file is critical and it feels that the XML grammar produced by the "save as XML" is likely to still change.
So while it is nice to see that is coming, it has little or no practical value beyond allowing us to start strategizing about what kind of tools we need to make this work.
I'm really pleased to see this sort of tool being developed too. Like add-on modules, and the data migration tool, the movement in this direction makes a lot of sense.
I do wish they would publish the DTD, even if it is a work in progress. For one thing, developing and publishing the DTD would give us an opportunity to extend our toolkit and an opportunity to contribute to the development of it ( via comment/request ).
We had to do an upgrade to an existing, smaller solution last week - and I was about to test the migration tools, but then I decided to do it manually because it was done in about an hour and I knew that the customer want's some changes right after testing it - and I would have to spend much more than this hour when testing...
Data Migration Tool is solid. We use it all the time. Smaller solutions complete in seconds. Importing data the normal way for our files takes 36-48 hours. DMT on the same files takes less than 45 mins.
As for the Upgrade tool, it's a great idea. But it's not ready for a production system, in my opinion. At least not yet, anyway.
Yep, we're heavily into the DMT. Our own wrapper tool around it "YADMT" takes full advantage of separate threads to work through a set of files in parallel to minimize the overall time.
Once we get insight into the DTD for the XML schema grammar then we'll be able to use similar tools to diff solutions, make use of versioning control; roll-backs, roll-forwards,... it'll be fun.
Hey @Malcolm, I am unsuccessfully trying to use it.
My use case is to update a script, but I cannot create the appropriate patch file. Do I need to update the script steps 1 by 1 and then add new script steps ? How would that be constructed, I tried the following patch, but it did not work. My assumption is now that I need to update script steps 1-1, so I don't provide an object list because the ReplaceAction does not support it, and then add new script steps ?
My experience of the Upgrade tool is still limited. I know that there are plenty of things that can potentially go wrong. I followed the instructions using a very simple test case and found it difficult.
I find it quite unwieldy. Manual editing of large xml is error-prone.
In order to stitch together something like a full development cycle, I'd have to rely on at least two 3rd party tools in addition to the vendor's collection of tools.
