Well, I have had fun over the last couple of days; upgrading this web site blog to the new version of WordPress.
It all started with the need to upgrade the underlying operating system on the virtual host that I have. It was a very old version of Fedora Core and I now had the opportunity to upgrade to CentOS 5.1, which I prefer.
So, I backed up everything, in multiple ways; ftp’d all the html, exported all the MySQL databases and then used WordPress’s inbuilt function to export out all the posts, categories, links etc.
The actual os upgrade was simple. Login, select reimage from the menu and come back within the hour. Good. Done. Easy. And it worked.
I restored a couple of plain html web sites and then started work on this site.
As a new version of WordPress was available last month, it seemed like a good idea to install it as new and then import all the articles, pages, etc. This went reasonably well. A few minor hiccups with plug-in settings not being saved. I had done screen dumps (to pdf’s) of all the setting pages before starting, so it was just a hassle to search through them all to find what I had used before.
Then I noticed that all my links had gone. OK. WordPress does not export them or import them correctly. I reloaded them from the MySQL dump files. Links are back. But there are no categories for the links. I reload them from the dumps also. Now things got interesting as I had to overwrite the current categories table with the old data. This made all my articles have the wrong categories. Why?
Well, the cataegoires are shared between the links and the articles. That is fine. But when WordPress imported the articles, it created new record keys and adjusted the article categories to match. As I overwrote this information, the keys changed and the relationship between the articles and the categories broke. This is what happens when you use a sequential number for record keys.
I have noticed that this is a common method used within SQL based database systems and I really do not like it. There is no actual relationship between the record key and the record contents.
I personally prefer to use a key which relates to the information within the record, in some way. The issue of sequential keys also came up in the U2 mail lists last week. The use of a unique sequential key using date, time, port number and multiple reads to combat the lack of resolution within the time variable and the issue of faster processing power of systems.
So, now, the categories are not correct for the articles. I will be manually correcting them over the coming week.
But even non-sequential keys can be a problem. It reminded me of a contract job I was involved in last century, of loading information from the existing core system to a new accounting related system running AP/Native on a Compaq PC (remember those days?).
As the transfer was going to be daily and updates to existing records might be needed, it was necessary to identify a unique key value from the core system which does not change. Then new records can be identified and updates to existing records can be identified. All is well. Except, each morning, I was getting complaints from the accounting staff that duplicate records were being produced.
I had asked the gatekeeper (IT manager) what data to use for the key generation; and entry/admittance date and time fields were selected. As the original information is ALWAYS entered in manually, date and time has enough resolution for uniqueness. But what the IT manager DID NOT know was the data entry staff were so busy that they would often enter in values of zero for the date and time (the system let them…) and then update them later. Maybe the next day or so…
So, as always and it is often the case, where the powers in the ivory tower do not really know how the system is being used, abused and bent.
A quick discussion and a long lingering dirty look at the IT manager soon sorted out the issue.
Overall, this was rather a nasty project as I believe it all went bad two, three years later. What could go wrong did. For instance, I would change a routine or two on one day and the next day the routine was back to the original again…
I honesty thought that I was going nuts, being too stressed out and just loosing it. So, I relaxed, made the changes again (this time better!) and continued forward. Next day, some of the changes had gone again…
OK. Someone is screwing with me with restores…
No, it appeared that AP/Native and Compaq did not mix that well. Some time in the night, around midnight or so, the whole system would not flush to disk but just clean all it’s buffers. So , all data still sitting in the buffers that had not been written to disk was lost.
So, make a change, reboot, make a change, reboot. The users were at the door with pitchforks and burning touches…
The good ‘ol days, NOT.