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.

What an ORM?

>>2
An inferior form of JSON.

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.

Here is an example of such an algebra fitted for an OO environment. In this case ruby:

http://db.inf.uni-tuebingen.de/files/publications/off-the-beaten-track.pdf

As you can see, every statement is executed in the database and the statements are composable and thus reusable. This is a huge difference between ORM's, where the generated shit can only be used on a particular database.

>>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.

>>6

That sounds as a reasonable compromise. I didn't know about Hibernate. But HQL is a relational language, this makes hibernate a hybrid approach of an ORM and a relation language.

>>7
Yes, it has a builtin relational language. Something I like about Hibernate is that you can build queries either by writing HQL code or by using their composable "Criteria" API.

List cats = session.createCriteria(Cat.class)
    .createAlias("kittens", "kt")
    .createAlias("mate", "mt")
    .add( Restrictions.eqProperty("kt.name", "mt.name") )
    .list();

This allows you to build queries dynamically without concatening a bunch of strings. The query I quoted joins three tables to populate the Cat objects' associations.

Hibernate is ENTERPRISE shit and so is this thread.

>>9
Cry more little Scheme kid



     (   )
  (   ) (
   ) _   )
    ( \_
  _(_\ \)__
 (____\___))

>>10
Back to /g/, code monkey

>>6
pretty sure >>4 is trolling you.

at least i sure hope so.

>>12

I was quite serious, ORM's are troubled by their inability to map all relational constructs to objects. I am not the only one, who thinks this is a problem:

http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html

But hibernate looks more promising to me, because it has a more hybrid approach. I see much more future in approaches like LINQ. Another approach is an object database. Unfortunately for OO programmers these things seem to have failed.

>>13
Note: Hibernate is not really "promising", it's a large million dollar project and the de facto standard for persistence in Java. NHibernate is probably the most popular persistence framework in .NET (I don't know how Entity is doing these days). Hibernate is pretty old already.

>>13
It hasn't stopped firms like Workday from fagging up the marketplace.

I was trying to post "databases considered harmful", got back this:

A fatal error occured!
That password is wrong!
What the fuck, Shii^tchan?

>>16
Maybe its database was corrupted.

>>17
lel, there is no database.

>>13
After reading that post, I'm confused.  If developers are wailing and gnashing their teeth at the notion that their pet languages don't handle sets or lists very well, why don't they use Lisp?

>>19
Because they're too busy stuffing their faces in Javashit.

>>19
Because one thing has nothing to do with the other. The problem at hand is the "object-relational impedance mismatch", not the "language support for parenthesis matching impedance mismatch". If you don't use object orientation in Ruby you won't run into the impedance mismatch. If you implement OO in Lisp you will run into it.

>>21
common lisp has multiple dispatch, which can do more on its own than single dispatch oo offered by the other mainstream languages.

Please explain to me how MD solves the ORM problem.

>>23
The MOP solves the ORM problem.

>>24
Fuck off.

>>23
That was in response to ``If you implement OO in Lisp you will run into it''

MOP doesn't do anything that can't be done with in smalltalk style oo with some more syntax. But the ORM problem can be solved with symbolic computation, which lisp is ready to do.

>>26
That's a hand-wavy claim. The end result is you are solving the mismatch by ditching the object model for the relational model.

If you want something that looks like an ORM to the user without having the mismatch, you can use relational programming to pre-generate an object interface that actually works. You will end up with an application-specific ORM. I don't think it's been done.

>>27
Yeah, it would take some work. You would need to write the rules for generating the efficient queries you are looking for. You would need to be able to specify what fields you are actually interested in getting and things like that to take advantage of that loading the index optimization mentioned earlier. But it can be done with some computer algebra. Make an engine with some rules for substitution and a heuristic for what forms would perform better, then do a heuristic search for a more optimal equivalent form. These expressions can usually be evaluated at compile time, so you can put time into it.

You could even adjust the backend to look for different forms in each backend implementation.

>>28
Have you heard of miniKanren? If you're dedicated, you could probably get it to spend a million hours computing an acceptably-optimal specialized ORM for you based on your program. But you have to Kanrenize the relational model and the object model.

>>29
That sounds like fun.

https://en.wikipedia.org/wiki/MiniKanren

αleanTAP is a program written in αKanren, an extension of miniKanren for nominal logic. Given a theorem, it can find a proof, making it a theorem-prover. Given a proof, it can find the theorem, making it a theorem-checker. Given part of a proof and part of a theorem, it will fill in the missing parts of the proof and the theorem, making it a theorem-explorer.[1]

kekekekekekekeke

>>30
And this stuff is as old as the sun. All that's changed is it's better/purer/smarter than it was and "it's pretty darn fast now."

>>25
Kill yourself cunt.

The MOP solves lots of problems, from muddy footprints to vomit on the floor.

>>33
The vomit induced by ENTERPRISE QUALITY code, yes.

>>32
Hi, you must be new here.

>>35
This may surprise you, but I invented the ``This may surprise you, but I invented the ``Hi, you must be new here.'' meme.'' meme.

 Kimi to Kanojo to Kanojo no Koi was poorly written and had little going for it other than the meta gimmick. Only play it if you're really interested in having someone preach at you about how horrible a person you are for playing eroge

I was offered a position at a Japanese chemical company, starting stateside, and moving to Japan in a few years.