It's all about the legacy

It's been a while since my last post. I've been tied up with job hunting - I got an offer of a new Delphi job but then turned it down when my current employer offered me a brand new Rails project (where I handle everything, marketing included). This new project is going to be a more "traditional" setup - Apache, MySql, Linux (at least initially). At some point in the future, we will probably want to move it on to our Windows Servers but I may stick with Apache. Or just proxy to a cluster of Mongrel processes.

But, as I have been asked, I'll let you know how far I got with my Railsifying our existing application.

The app had logic stored in both the Delphi objects and the stored procedures. So we worked pretty hard to rationalise this - moving it all into the stored procedure layer. As the existing stuff did not follow any hard and fast naming conventions, I added a new layer of views above the tables that rigorously followed the Rails conventions. And then I created a new layer of stored procedures above that ... these follow a convention of entity_insert, entity_update and entity_delete. The parameter names where generated from the associated view. Not every entity had all three stored procedures (I will return to this later). Then came the (not small) job of adding code to each proc making it call the relevant procedure in the "old" version of the code. This is still ongoing.

This meant that my Rails model objects could select from a view that followed Rails conventions. Next up was to get them to call the relevant stored procedures - I override the save method and made it call "entity_insert" or "entity_update" (using my stored procedure code) - it could match the parameters to field names as they now followed a convention. And at this point I stopped my Rails work.

The reason for this was the decision was made to build a new web-service layer over the application. The Rails stuff acted as a starting point - we would reuse the Rails-style views and the Rails-friendly stored procedures and use them as the basis for the new service. If an entity did not, for example, have an _insert procedure then the new service would dynamically generate the Sql to do the insert, if it did, it would call the relevant procedure.

All this left my existing Rails work out of date and I've never had the chance to update it. When I do, I have two choices - either rewrite it to call into the new (SOAP) service or just adapt the stored procedure code to dynamically generate Sql when required. Before I could make a decision, I was told I was not allowed to use Rails any more. So I found a new job and, lo and behold, a brand new Rails project was conjured up to prevent me leaving.

I'm working on the new project most of the time now (been reading up on business strategy and marketing techniques as well as ploughing through Rails Recipes and Agile Web Development 2) - so I've not had the chance to revisit the old code. Ideally I would rewrite my Rails models as SOAP clients (similar to ActiveResource but in SOAP) so the service becomes the point of centralisation. It may just be quicker to keep the Rails models talking directly to the database (meaning that the stored procedures become the point of centralisation). I don't know and I've not had chance to think about it.

I will keep you posted. Thanks for reading!