And here we go!

Gee has it really been nearly a year since my last post I must be getting very lazy in my old age.

Well I do have something to blog about these days besides new modules and unused D&D code. Lets start off with a little background:

It all started back in 1998 or was it 99?? I was working with a really good JAVA team at the time, yes I know sacrilege. We created a number very good and well selling products for a suite of SIP servers, as a matter of fact I am still getting royalty checks after nearly 20 years, and they said I was dumb not to take the share offer in lieu of royalties.

The core of these products was a JAVA back end app that was used to access the varied DBs that managed the SIP server and client info. On fine day a few years later, the service desk started getting calls from customers that a large number of accounts where be compromised on their SIP apps.

In the end it turned out the SIP servers where being subjected to SQL-Injection attacks which was traced back to that killer JAVA back end and these few lines of code:


else if (operation == SQLDataAccessor.EQUAL_TOSTRING))
return(colName + “ = ' “ + constraint + ”'”) ;

Opps seems someone was not watching out for their parameters. Well these where early days and this was the first SQL injection attack I had ever seen.

Well fix the problem with a little encapsulation sub and it never cropped up again. Of course the question arose 'why didn't you use an ORM'. Well back then there was no ORM that you could afford to put behind a web site and have many ten of thousands of transactions an hour and thousands of connected users. At that time you are money that the 5 Big could hardly afford.

Now lets skip ahead a few years, a failed company or two, and a number of downsizings, and I eventually ended up in a shop where I re-joined some of the core members of that JAVA team still working on SIP servers. This time the idea was to develop a SIP stack with the Linux LAMP.

At this time there still was not much in the way of open source ORMs for any language though there where some fine JAVA ones out there and some really bad ones like SmallTalk but again nothing was cheap let alone Open Source. The team lead asked if we could recreate the old SQLDataAccessor but this time in PHP.

After 8 weeks of useless effort the boss said “I want it now” just do it in any language that will work on on LAMP. So this is where Perl comes into the mix. Well we tried some Python code and got nowhere fast and then a team member suggested we try the new killer Perl 'DBI' app, in those days we called most module like things apps.

So as Lauri Vuohensilta says 'and here we go'

Now the lead programmer was going by memory and the paper copy of the JavaDoc I had had from my desk at home and with just that we managed to have a working example up in a few days. Well turns out that good old DBI solved many of problems we had encountered with PHP and Python and even the original JAVA.

So the Perl mod became the core chunk of software for a number the LAMP SIP products the company produced and as far as I know the code is still clucking away after nearly 15 years with only one version '0.01' ever being produced.

So what has this got to to with Perl blog besides a little history. I have been using this code for almost 10 years in a number of other projects and companies and it always seems to fill a need but it never made it to CPAN.

It is however getting rather long in the tooth and I think now is the time to bring this code base into the 21st century.

So I guess this is part one of many to follow as I take SQLDataAccessor into the future.

Here is a little hint on where I am going


Leave a comment

About byterock

user-pic Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations