It’s been a while since I wrote a post about MixAction and what I have been doing of late. I’m still coding and am very pleased with how things are unfolding on this front. There’s still a ways to go yet – but the product is getting closer to a release. It’s more rounded now, but there are still ongoing tweaks and improvements that are best made before the product goes “live”.
I’ve mentioned in this blog in several posts that I’ve changed the playlists to lists of “objects” rather than lists of media files, without going into full details as to why or how. I’m not going to go into those full details yet – in fact not until after release. But I will, eventually… 
Suffice to say though that when you make sweeping changes such as this other things need to change and in some cases even parts of your coding methods change in accordance.
Thus the “Project File” format in MixAction has been updated – again. Once again I’m glad I’ve done this now.
One of the things that bothered me is that adding fields, in version updates, to a database table while not impossible is tricky in Delphi. You can do it using Ttable objects for most database types – or you can use SQL to restructure. The “Project File” format is a TdataSet descendent and so automatically supports these methods.
What bothered me is that in the past there have been occasions where the changes corrupted the dataset in projects I worked on in years gone by. I wanted to avoid this – for obvious reasons.
In addition customers often have local issues that for a variety of reasons cause the updates to not go as expected or as planned by the dev. It is their data and for most people things get a little confusing – and harrowing.
I have a lovely commercial component library for importing and exporting datasets (which I use a lot) but in this instance it isn’t the solution for this problem. The solution, to my mind, was simplification of how things are stored.
The solution was to apply a kind of virtualization of field objects. Instead of having separate fields for each “property” for given functionality (remembering the person using MixAction has various ways of preparing a media file for playback) I’ve taken the contents of the playlist and streamed them as blobs into the dataset. This was the case anyway – the data was already there in that format to save the hassle of using temporary files for playlists going right back to June.
As the product evolved what happened was a kind of redundancy occurred whereby the data existed both as individual fields and in the streamed data from the playlist.
It no longer made sense to include this redundancy – project evolution meant that a more efficient method could be used. Efficient in that one field becomes, in a sense, two dimensional and the whole table is reduced from twenty or thirty fields (potentially growing with any new features) down to three.
As the playlist is now a collection or list of objects in the visual/operation sense now so it is in the development sense. Once again saving bunches of coding (important for future maintenance, expansion and debugging) and in the process creating a re-usable object on the component palette for use in other related applications.
Add a new parameter to a playlist object in a new build – no problems. The object is updated in the IDE and the new parameter (field in a sense) is added when the playlist is streamed to the dataset by the customer. Customer decided to use an old project? No problems, no manual or interactive upgrade of the Project File (database) needed. It’s handled as part of the normal streaming process.
Customer wants to go back to using an older version of the program? Again – no problem, the new “properties” are gently removed by the streaming process and the project file is downgraded again. Original data is not lost.
No restructuring of the datasets true fields are required.
Undoubtedly there will be times when a true restructure will be required – but using this technique I can at least aim to not have file restructuring occur short of a new version release as opposed to minor version changes and tweaks. It also makes the creation of advanced versions easier as less consideration needs to be given to the dataset in advance.
You could argue, and in many instances you’d be correct, that proper planning and design would mean there would be no surprise additions.
The reality is though that there are an unlimited number of potential parameters for the future that in this instance simply can’t be spec’d. So flexible and seamless works for me here. It also assists in the time it takes to add a feature – no more time than the code to make the feature happen without having to worry about field updates or bother the customer with overt backups and so on that invariably need to occur and so rarely actually take place – even when patently requested by upgrade wizards and warnings, or when handled automagically by the product.
As the project file is a local file and playlists are unlikely to ever be more than a few thousand rows (if not far, far less) each of the usual problems of speed that would make this icky don’t apply as they would if one was designing a “normal” database.
Hoping to get some new screenshots up here in the next week or so…
Scott Kane
Quote of the day:
Reminds me of my safari in Africa. Somebody forgot the corkscrew and for several days we had to live on nothing but food and water. – W. C. Fields
