Model Operations Processing System

Tidying up continues.  It’s a known feature of programming that a program can always be ‘improved’: one of the reasons for imposing deadlines on programmers is to make sure that they don’t continue ‘improving’ the program forever.

MOPS is suffering from this, a little; although the revised code is stable, the opportunity couldn’t be missed to also tidy up the code a little more.  Will the time taken in ‘improving’ the code be offset by a reduction in time later?  Don’t know.

It’s expected to take a further two weeks before new code is being cut again.  On a more positive note, the project completion date probably hasn’t slipped very much.  Once development is rolling again, a revised schedule will be issued.

If you have been following these posts then you will be aware that a problem was encountered with data corruption when a number of concurrent usesr were hitting the same data files.

This problem has now been solved.  There’s some tidying up of the code to be carried out – it was important to get to the point where we had stable data – but once this tidying up is complete, we should then make good progress.

First, the rebuilding.  The Railroad and Parameters modules have been rebuilt, and work continues on the User module.  After that, there are a further three modules to be rebuilt before a further volume test takes place; but irrespective of the results of that test (providing the test is not an absolute failure) work will continue with SQLite.  The reasoning behind this is that if higher transaction volumes are required, then making a version of MOPS available with MySQL in the future wouldn’t be too big a step change.

On building: I’ve been using Scalescenes downloads and the Model Builder software to create card-based structures in N gauge.  I like both products and I’ve added links to the web sites on this page.  It generally takes three versions to get a scratchbuilt structure looking generally right, but the process is fun.

Some time has been spent today becoming familiar with how SQLite fits in with Python; and it has been reasonably painless!  A couple of transactions have already been built for MOPS, and the aim now is to convert a substantial amount of MOPS to use the SQLite database and then to give it the same kind of testing that surfaced the problems with the file-based key locking that was uncovered earlier in the week.

Assuming that there are no horrors lurking in the testing, then development will continue with SQLite.  This approach will provide an option to switch quite easily to a server-based database (such as MySQL) if necessary, or even to simply provide it as an option (when an add-in is available for Python).

The implementation of SQLite from Python is amazingly straightforward; it’s built into Python itself so there are no concerns about implementing databases and other related issues.  At some point in the near future the database will also be tested across a network, including accessing the Windows-based database using MOPS running on Linux.

Further to the post earlier today, it appears that there may be a while to wait for MySQL to be available to Python users: Python v3 is not that long out of the box (and that is what MOPS has been written in) and the MySQL adaptors are still awaited.  So, it’s a choice between persevering with a home-grown version of locking software, or switching to SQLite and hoping that the issues disappear with that.  More later…