Posted 7 years ago.
I recently received comments which are very very useful to know what people think about Pomm project after just having taken a glance at the official website. I will comment back here a couple of negative comments.
Let's begin where it hurts:
Pomm claims no to be an ORM but I do not perceive the difference. It looks like Doctrine with less features and specific to Postgresql.
Well, this indicates hundred of people who visited Pomm's website left thinking the same thing. In fact, Pomm shares almost nothing with Doctrine as the underlying philosophy is utterly different.
Pomm does not need the high level abstraction of an ORM because it relies on Postgresql's features. Postgres already has some object oriented features. You can manage data from tables as they were objects and fetch relations directly in your SQL queries. Pomm with its converter system takes advantage of that. Instead of trying to create an object abstraction over a relational set of data, it just transposes what's in Postgres to PHP.
This is a big win because the 40 years old SQL language has been made for querying and presenting data. Developers using it are able to directly extract from the database the data they want presented in the best way for their business process needs. This makes the PHP code slim, fast and easy to test. This is also a big win from the performance perspective.
ORMs is what you get when object oriented programmers code a data store over a relational database. Postgresql is what you get when relational database developers code an object oriented data store.
On the other side, PHP which is often bashed for the weak typing and its loose object structure is a perfect match when it gets to be married with SQL. SQL is a strongly typed declarative paradigm language dedicated to the data crossing and presentation. PHP is an imperative paradigm language good at creating web workflows. It can map elastic objects over result-sets returned by SQL as soon as you sandwich a nice data converter between those two layers. This is what Pomm is. Let Postgres manage relations between objects and return you the data your business needs so Pomm map them to PHP objects.
Pomm's converter is the most tested part of Pomm. It allows you to fetch from Postgres objects that contain arrays of objects containing arrays of objects and so on. It supports HStore key value stores and map them to PHP associative arrays. It supports Pg's geometric types and many more (xml, json, ranges etc.). You can even define your own types like you would do in an object oriented paradigm and tell Pomm what PHP representation you want to link them with.
In an ORM world, classes are strongly coupled to tables, with Pomm, classes are loosely coupled to sets. You can define a map class that is tied with VALUES ('pika', 'chu'). Of course the findAll() method of such class would always return one instance with the same values but isn't that by example what you want in a test suite ?
It is not my intention to reopen the ORM war here nor to say bad things about Doctrine. As another comment said:
Doctrine2 is all-right for all the developers needs.
I do valve amplifiers as a hobby aside my real job and I started working steel enclosures with a Dremel. I found this hard, I was very bad at it and the result was just acceptable. I am not saying Dremel is bad -- I still use it almost everyday -- but since this time I have bought a professional drill set with a real drill and guess what: the job is perfect and done in less time. As the implementation part stopped being an obstacle, I began to have new ideas I couldn't even imagine before. On the other hand, I cannot use these drills on a concrete wall nor a piece of wood without damaging them and obtaining poor results. That's a question of choice, mine is to use the right tool for the right job.