Table of Contents
When we previously looked at the Wacs Model Manager back in Chapter 6, wacsmodelmgr - The Wacs Model Manager, we were concentrating primarily on it's features related to creating and amending model records. It is actually capable of quite a bit more than this, particularly in the areas of IDmap and download record handling. In the section called “wacsimport - Importing Model Details” in Chapter 12, Migration Tools we mentioned in passing that the model manager can also handle the importation of model XML files. In this chapter we're going to look at those additional features and at the roadmap of where the development of the model manager application is going.
A key thing to realise is that the Wacs model manager is still the subject of pretty active development and is likely to see significant improvements over the next couple of Wacs releases. To this end, and to help clarify why we're covering only some features and not what might appear to be obvious others, we've tried to lay out what the current state of play is. The table below gives some indication of what works now and what is expected to work in the near future.
Table 15.1. Current and Planned Features in Model Manager
| Feature | In 0.8.6? | Description/Notes |
|---|---|---|
| Add New IDMaps | Yes | Use Identity Management Mode |
| Edit/Delete IDMaps | No | Planned for future release |
| Import New Model From XML | Yes | Use Model Update Mode |
| Update Model Details From XML | No | Planned for future release |
| Add new IDmaps From XML | Yes | Use Identity Management Mode |
| Add new download records from XML | Yes | Use Identity Management Mode |
| Update IDmaps from XML | No | Planned for future release |
| Update download records from XML | No | Planned for future release |
| Update Web Site Owner Info | No | There are some currently inaccesible fields in the model database for use by Web Site owners in relation to models. This function will allow use of these fields. |
The Wacs model manager can handle the XML files created by the wacsexport command, but initially only to a limited extent. If you consider the state of play as regards any given model and an XML file containing her details, you can see that there are five obvious states:
- The model doesn't exist on our Wacs system
- The model does exist and the XML file has additional information
- The model does exist and the XML file has less information than we do
- The model does exist and the XML file has conflicting information to what we have
- The model exists and the information is the same.
As of Wacs 0.8.3, the first of these is implemented in full - upload a Wacs model XML file and if the model isn't known, her record will be created. The third of these isn't really a problem for us although it might be nice to contribute back whatever additional information it is we know. The fifth of these is also relatively easy as the model manager just loads up the relevant model's record to say “Hey, we know her, and here's her details”. It is the second and fourth options that require more work and do not currently work as you might expect in Wacs 0.8.3 - at present if the model is known to Wacs, her record will simply be shown but no indication will be given of differences. The second will be the next part to recieve attention so that any field that is empty in our Wacs database will be filled in by values from the XML file.
Now that we've defined the terms of reference and you have some idea of what will work and what does not, lets just look at the steps involved in importing a new model record from the XML file.
 |
It is quite a simple process to browse to whereever the XML file you
want to load is, choose it and then click on the Upload Model XML
File button. Do remember that the sample files we're using here
can be found in /usr/share/wacs/samples/models on versions
of Wacs installed by package, and in the samples directory
of the unpacked tarball if installing from that.
![[Warning]](images/warning.png) | Warning |
|---|---|
The model manager XML import system uses existing IDmaps as a way of determining if it already has the model concerned in it's database. If you have a number of models with no IDmaps set, it could easily import a model twice. If in doubt, check your model directory before importing the XML file. |
 |
Here we see all the information from the XML file filled into the normal model update screen as we've seen before with the usual Summarise Changes button included. The only sign that this is an XML import is the title at the top of the screen (although hopefully that is screamingly obvious!). As usual, check it over, particularly looking at the model attributes which could be different on your system than on that which created the XML file in the first place. It's quite possible to change any of the values you disagree with here before creating the record. Once you're happy, just click on the Summarise Changes button to proceed.
 |
We now see the summary of the information that the model manager is about to use in creating this record including the actual SQL is has written to do the deed itself. So long as you're happy with that, just go ahead and click on the Commit Changes button.
 |
This is the final screen of the XML Upload conversation and as you can see it's fairly busy. The top bit relates to the actual creation of the model record itself and is the repeat of what happened before modulo any changes that have happened since (like someone else creating another model record in which case the model number we get will have changed). The next bit shows that we've added an identity map entry, in this case for KPC (Karup's PC), and the final piece mentions that it has also imported thirteen download records for this model. That is a part of the model manager code that is unique to the XML import feature - it can also be used to import new IDmaps and download records for an existing model but we'll discuss that feature in the next section.