Locations have information about then, for organization. They're in a country. Sometimes in a state. And they're in or near a city.
But we don't have tables of countries and states and cities. It's just a string in the locations table.
In my model, I have country and state and city objects, but they were entirely virtual, generated from the data in the locations table.
Country.find(:all) would pull all the country codes from the db, along with counts, and create an object with a code (BRA), a name (Brazil) and a count (458). And from that, you could ask for states (select state as code from locations where country=?) and so forth.
In working on the submission system, I came across code that validates state names for specific countries. The US requires you to use the state abbreviation. For canada, brazil, australia, and finland, you have to specify a state in a specific list, or it bounces back an error and lets you choose from the available options.
After beating my head against UTF8 vs Latin1 source-code encodings vs database-encoding vs string comparison, I decided to shove the information into the database.
So, all the country code/name mappings have been put into a countries table. And the states name/name or abbrev/name mappings have been put into a states table, for those that I care about.
Which means changing the country and state models into activerecord objects.
While still being able to deal with virtual records, say for countries that we don't validate states, but which have them (UK, frex).
So, they all now have some very complicated .find methods, which will find them if they're in the database, and fake it if they don't.
That's what I spent all of yesterday evening working on. It's all back to working exactly as well as it did at the beginning of the evening.
Tonight, I will try to actually get the submission handler working.
I still need the signup handler, the google-maps and google-earth redirectors, the comment submission handler, the category submission handler, and the edit/approve handler.
In short, the things that modify and create data are all that's left to do. Plus maybe a couple other little tweaks.
And then setting up an account with google, and implementing the ad code on the new site.
And then making sure caching works. And making sure things that change data expire the correct caches.
And then profiling, to make sure it's at least as fast as the old system, and preferably much faster. (the home page will probably never be /quite/ as fast, since it's currently served 100% cached, and I'm changing to a cached-in-pieces mode)
And then making sure fcgi is set up correctly to make use of the 8 processors on Moshtari.
And then changing all the DNS, shutting the old site down, migrating the db one last time, and bringing the new site up officially.
It /could/ all happen by this weekend.
It'll probably be a couple weeks yet.