Tuesday, June 4, 2013

New ventures and new directions for this blog

I have agreed to help found a LedgerSMB hosting business called Efficito.  We have a very basic web page up (which is in the process of further development) but we intend to offer hosting specifically of LedgerSMB 1.3 and higher to customers who want it.  If there is interest, please feel free to email me.

One thing we have committed to do is to leverage PostgreSQL for the overall management of our hosting services.  We intend to use the database as a point of original entry, allowing other processes to enact changes saved in the database.  This is something very different from a standard 3-Tier architecture in that the entry of data into the database triggers real-world side-effects in a distributed environment.

Obviously I cannot disclose our full codebase to the world, but I expect to be covering a number of aspects of how we will use PostgreSQL, and include small snippets of past or current versions of the code in these posts.  The examples will be naturally minimalistic and lack the context of the full system, but they should be interesting from a question of how one works with PostgreSQL in an automated environment and a number of other topics.

In essence what started off as a blog about LedgerSMB, which has expanded to include object-relational design generally, will now be expanded yet again to include database-centric automation.

I expect to cover  a few pieces in the near future including cross-type referential integrity where inet addresses match cidr blocks, and the use of ip4r to construct exclusion constraints for network ranges in table types.  The first post is probably more generally useful because understanding how to manually do referential integrity can help solve broader problems, like referential integrity over inheritance trees.

Anyway I hope you enjoy some of the newer areas of focus as well.


  1. Would I be correct in thinking of "database-centric automation" as having the same goal as the kind of automation some admins attempt to accomplish with Chef/Puppet?

    If so, I like the idea. Just thinking out loud... but if both config and log/performance info were in the same database, that might open up some interesting possibilities of for things like self tuning based on parameters.

    1. Yes, after a fashion. The idea is you could have a web application (or thick client) which manages the configuration of software and servers merely by connecting to and manipulating data in the database. When you commit, a message is queued up as to what service and server needs to be reconfigured, and a notification raised.

      Then a listener can get the notification, request the message (and get it), and then retrieve the information to make it happen.

      What this means is that the database becomes the place of original entry for configuration changes, and then the rest of the application environment just makes it take effect.