So the current project I am working on at Liip is based on Symfony2. The first sprint went surprisingly smooth. The second sprint we are currently in now "fixed" this growing perception that this pre alpha code just might be stable already. Anyway, we knew what we were getting into but still felt it was the best way to go, no regrets. The main source of trouble is the fact that we wanted to make use of DoctrineUserBundle, but load the views via JSON. Unfortunately right now there are quite a few issues with taking a 3rd party Bundle which wasn't specifically build to be accessible via JSON. So in the end I build a MultiplexController that can JSON-ify any controller. The name derives from the fact that it also supports calling multiple routes at once and returning all the data from all these routes in one request.

So I heard rumors that one of the teams at Liip was struggling with the performance of a symfony app, which was casting doubt on symfony in general. Now that team solved their performance issues by using a filter to do some aggressive caching. This fit nicely in the content workflow anyway since updates do not come in all the frequently anyway. So they just cache everything and added a feature to prime the caches for content changes. Problem solved, but doubts remained for other projects. So I wanted to figure out what was going on.

As I blogged recently we started working on CouchDB support on top of the Doctrine2 infrastructure back at FrOSCamp. For me its been a while since I have taken a leading role in the development of an OSS component. Ever since I left PEAR, I have mainly been helping out here and there and with php.net I was doing organizational stuff. So its kinda fun to be back at working on some OSS code with significant contributions in terms of code. There is still a lot of work ahead, so I wouldn't mind a few helping hands, But you may wonder why you should even bother. Like I was in #couchdb on freenode the other day and David asked a fairly legitimate question: "can you enlighten me as to why you'd need an ORM on top of native json object"? In this blog post I will try to explain why it makes sense to add a model based infrastructure underneath a NoSQL database.

Recently it seems like pretty much all projects here at Liip are using Solr in some form or another. Never thought that all my PHP projects would end up relying on Java. This is just a short blog post to document an approach I came up with to make delta updates more efficient and at the same time easier to maintain than the "standard" approach explain in the docs. The Solr DIH handles importing documents from external data sources. In my case I have about 5GB of data in an RDBMS that gets updates every night. The standard approach in Solr is to define one query for the initial import and a second query to fetch the IDs of documents that have changed and a third query to fetch the data that changed. Especially if you expect a large number of changes this isn't very efficient (*). Furthermore if both in the initial import and the delta case you have the same SELECT list, its tedious to maintain 3 queries where two are almost identical and one still very similar.

So thanks to the sponsorship of Liip we managed to get quite a few people from outside of Switzerland for some pretty exciting meetings to Zurich for FrOSCamp. Plenty of Liipers were also present. On Friday we sat together to learn and talk about Symfony2 CMF. On Saturday we split up in two teams, one working on the JCR client library Jackalope and the other starting with adding CouchDB support to Doctrine2.