Saturday, February 7, 2009

Lots of progress

Since the last time I wrote about actual feature development a lot has happened.

application_id is no more
Per my previous post on application_ids I decided to get rid of them. They are now gone. That means updates to
  • migrations (removed all the application_id
  • model relationships (has_many and belongs_to are not straight forward)
  • the legacy importer now looks up IDs and assigns them instead of using the application_id
Fixtures
I'd been using test/fixtures via rake db:fixtures:load to import some baseline data and constants into the dev and production DB. Once I started writing tests this didn't make sense anymore because the test fixtures were clobbering the production DB.

So I created a db/fixtures directory and told the migrations to load those fixtures. Now the baseline data is imported into the DB when I run rake db:migrate:reset

Communication with the Generator

As I thought though the communication from the controller to the generator I realized that I was going to have to rewrite the generator property loaders in order to read whatever format I wrote the site properties in from the controller.

Dreading that task I had a thought. Why not just have the controller render the site properties and other generator config data in the exact format the generator was expecting. So I did.

Taking it one step further I realized there was no reason to send this info over ActiveMQ. Since the controller and all the generators are connected to the same file share, I simply told the controller where the site directory was and then had it write the property files needed by the generator.

Arguably, this is going full circle. I just did all this work to import all that information out of the legacy files and into the DB, and now I'm taking it out of the DB and putting it back into the files!

But the benefit is a rapid development and test environment. It's trivial to bring the existing generator up and running since the site directory looks EXACTLY the way the generator expects. This allows me to focus on the main goal of the project. Centralizing control of the application and generation scheduling in the controller.

At this point the controller knows how to:
  1. Create a site directory from scratch
  2. publish site_properties.xml
  3. publish queries.xml
  4. publish the owner lists
The upshot of this dev work is it forced me to build all the relationships between most of the Models in order to be able to generate the content of those files.

Skipping Projections
I did NOT publish projections yet. Graph generation is one of the few parts of the generate I'm changing. I'll likely dynamically generate projections from the controller so they are always up to date. I'm leaving projections until I tackel the graphing part.

thesis.next
It's time to get ActiveMQ up and running for communications between the controller and generators.

No comments: