ORM patterns

If there's one reason to pick FIOC over Ruby, it's the ORMs that exist for each language. It's 2013 and Ruby doesn't have a single Data Mapper implementation. Even the gem named "DataMapper" is actually an Active Record impl. Everything in Ruby is AR all the way down.

AR is a terrible way to approach persistence. It forces you to tie your domain logic to database code. It makes unit testing close to impossible (no, Rails faggots, you're not doing unit testing with your sqlite db). When you open up a class file, you don't even know what the hell the attributes are, because they'll all be implicitly derived from the database. There's no domain model with AR. You can't even require your fucking classes in a shell because of all the database tie ins.

What's puzzling is that Ruby is so well suited for a good Data Mapper ORM. And the way Ruby handles OO is so appropriate for a pure Domain Model architecture. Ruby has all the tools, but nobody's doing it. Why? Why don't people use simple PORO classes for models and business logic and abstract all the persistence bullshit to a DM implementation? I don't get it.

My theory is that Ruby developers are just ex-PHP developers who think they're awesome for not using PHP anymore. They try to hide their backgrounds, but that's the truth. They've never touched a large Java app so they have no idea that besides their flaws, Java apps can be very maintainable at high complexity thanks to frameworks such as Hibernate.

FIOC has SQLAlchemy, a decent Data Mapper implementation which of course doesn't force you to fucking inherit from something else and lets you write good, easy to test FIOC code.

Object relational mappers are retarded. The mapping between objects and relations and tables are ill defined. This harms performance in a non trivial way and complicates database usage.

For example in postgresql it is possible to put an index on two columns. If one selects from this table and projects only these two columns, postgresql only loads the index and don't touch the table at all.
This is a huge performance difference if we compared it with the approach an ORM takes.

The ORM needs all fields, thus postgresql is forced to load the table, then an object is constructed.

This can make a query 1000 times slower.

Another problem is that ORM can't map all concepts from SQL. For example it is impossible for an ORM to map a group by query. This query has no equivalent in object space. Thus forcing the user to do this in the programming language (which is slow), construct a view and an associated object (which is tedious) or do a raw sql query (which opposes the use of an ORM).

Building an associated object for every query is not feasible  in a general way. Thus an ORM is only useful for the most trivial cases. As last I would like to mention, that objects generated by orm's are not composable. Linking two objects at runtime doesn't mean that the two tables are joined in SQL, this means composability can only be reached at the OO level, but not at the underlying SQL statements.

I would suggest working towards a relational algebra, which can be constructed in object oriented environments (due it's sequential nature). This preserves the power of SQL and gives you composable queries. It can even express more complex concepts as group by queries, aggregates and joins. It also gives you control over the projections, thus enabling various performance advantages in the more advanced databases. Composability means composability on both spaces. If you compose two algebraic statements it means the objects and the generated statements are composed.