I have blogged about prepared statements a few times, which is what most people rely on (too much) for SQL injection protection. I say too much because they do not really protect code fully against SQL injection attacks and they come with a lot of performance hurting baggage. To sum up: prepared statements do not handle all aspects of dynamic SQL creation, they add network I/O and memory overhead and they tend to generate less optimal query plans. Some of these issues can be solved by doing client side emulation, but that brings with itself its share of issues and I have to agree with Bill and not Brian that parsing SQL should be left to the server.. So vendors, how about it? How about offering us a proper solution to prevent SQL injection attacks like I was asking for in my last post on the topic?

The current data on search.UN-informed.org is all inserted via an excel sheet importer. In the future we want to skip excel however and do the data entry right in the online database. For this I am working on the admintool. Right now all the tools are generated via the admin generator. However it seems the default dropdown's aren't really made to handle larger data sets. So in the filters and edit forms we run into issues since we have quite a number of tags, documents and clauses already. The numbers will only grow and its simply not feasible to load a list of 3000 options into a drop down. So I started to make use of the sfFormExtraPlugin, which provides a widget for autocomplete. However I had to add some features to really do what we needed.

In the past few weeks I have been working like a mad man on putting together a frontend in time for the UN-connected.org conference. I have joined the Un-informed.org team as the sole IT guy some time in September last year. Since then I have posted to find people to help me, so far only Dennis Riedel has come through, well and of course Liip who have donated hosting and several days of development time, without which the site would not have been possible. Stefan Sicher also stepped up on short notice to make the site look good. But without a full stack framework like symfony it would also not have been possible. The source code for the application is available online for anyone to see.

A few days ago I announced my retirement from PHP core via twitter and the internals mailinglist. Actually I have always felt a bit weird calling myself being part of "PHP core" since in all the years I have never added any code to core, actually I have only removed some code as it was being moved to PECL. Anyway whatever you wanna call it, I ended up in a position where I could participate in many core decisions and finally even helping Johannes RMing 5.3 together for about a year. And like most open source developers I did what I did because I personally cared about the project and enjoyed being part of something that helps so many people in the world. Obviously it also helped my career and my employer in many ways. So all in all I put in time and I got a lot of things in return.

One of the key features of NoSQL is the fact that its schema-less. Awesome. Of course I could just dump a serialized string of my "document" into an RDBMS and I could end up with more or less the same, but the big difference of course is that NoSQL (to me key-value stores do not fall under the NoSQL umbrella) still supports non hacky ways to interact with individual values inside a document as well as indexing. But while at first it might seem great to not have at the database enforce a specific schema, the app developer better have a good idea of his schema. Otherwise one developer might call a field "is_active" the next one might call it "isActive" and another one "enabled". I have little to no experience with CouchDB, MongoDB etc. but I am not really all that thrilled about schema-less for the above reason, what I want is no-cost-for-schema-changes, I do want a schema!