Many thanks, that explains a lot. :)

> DBIx::Class::ResultSet

I'd rather call this an SQL abstraction.

It's much like SQL::Abstract and allows to cover (almost?) all semantics of SQL queries.

But yeah, like I said I'm strongly associating ORM to "Active Records" and the resulting limitations.

And where do you draw the line between ORM and SQL abstraction?

OO and relational algebra are very different paradigms.

An ORM will force the class structure onto the RDB-schema.

It's only using a subset of SQL and can be mapped back 1-to-1 to an object model (of the particular host language, here Perl).

It's like a amputated creole, speaking English words with Latin grammar. But without the possibility to introduce new Latin particles to express the new grammar, forcing you to use costly workarounds.°

E.G. there is no "inheritance" in SQL.

An SQL-Abstraction attempts to express all or most of the SQL-Space inside the host language, like with a query builder.

It's effectively just a new SQL dialect, attempting to map 1-to-1 onto other dialects (like LIMIT vs TOP )

My impression is/was that DBIC attempts to have the best of both worlds, which also explains it's complexity.

For a long read why many people despise ORMs you may want to have a look at

Object/Relational Mapping is the Vietnam of Computer Science

(I'll skip the first 6 pages about US-Vietnam-War though. :)

This blog-entry had a heavy impact and was often discussed in both directions, you might want to google the responses...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

update

swapped "Chinese" with "Latin" for claritas in metaphora ;-)

°) or is it rather speaking Latin with English grammar? :)