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.

>>4
I think you misunderstand the purpose of ORMs. ORMs are not meant to be a perfect translation of relational persistence to the object space. They exist firstly to make SQL-related code less tedious, and secondly to abstract data storage into a non-specific API. Instead of writing a million SELECT clauses, you can trust the ORM to successfully generate 90% of the queries you'd run. Instead of breaking your entire application when you switch to Postgres from Oracle or MySQL, you can simply change the adapter and everything will magically work. They are not meant to be a solution for everything. Anyone who actually uses ORMs acknowledges this. You are still expected to write queries when there is no decent way to do them through the ORM or when performance is critical (and Hibernate allows you to do so without depending on a specific database, with HQL). In fact, the more experienced with SQL and database management you are, the more you can get from ORMs. I speak from experience.

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.
ORMs exist precisely because the mapping between objects and relational databases is ill defined. That's like saying "ORMs are bad because they try to solve the problem that they try to solve".

The ORM needs all fields, thus postgresql is forced to load the table, then an object is constructed.
Wrong. That depends on the ORM. If you do an explicit "Select Title, Slug from Post" (that's HQL) in Hibernate, the SELECT will be restrictive and Hibernate will intelligently populate only the Title and Slug attributes on your Post object.

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).
Have you ever touched an actual ORM? Hibernate not only allows you to build queries with aggregations and grouping, but it also allows you to compile and cache them both at code and at the database level. Besides, there are several different ways to handle GROUP BY queries in the object space. You don't need to be shy about creating an anonymous class or a small query-specific class for these situations.

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.
Again, modern ORMs allow you to join tables on queries. Of course, composability means a different thing in the object space, so each ORM tackles this in a different way. And if you have a query that is difficult to map with an ORM, all of them will have methods to facilitate manual mapping when it's necessary.