Interesting article on ORM.

Sums up alot of debate on ORM and its pros and cons.

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

funny guy

Actually the author of the article clearly expresses a number of my "gut feelings" about this. I just presumed it was my lack of education leading to a lack of proper appreciation for the subtleties of it.

It would be an interesting exercise in application design to re-design MODx to work with something like NoSQL.

I also think it’s correct that a tool should fit it’s purpose. Squeezing an object into something it is not meant for is indeed not very efficient. You can say even counterproductive.

Questioning SQL as a whole, though, is in my opinion the wrong approach. There are good reasons why SQL has been so successful for quite a while now. I think it just needs to become more flexible. By, maybe, extending the whole concept.

This discussion is far from new btw, there were people crying for a more object-friendly solution more than a decade ago.

Interesting comment RE nosql implementation.

The use of XPDO is one of MODXs biggest strengths, but also its biggest weakness. Essentially reinventing the wheel where ORMs such as Doctrine 2 hold a stronger position. For example, the upgrade to enable MSSQL wouldn’t have been an issue if MODX was based on a library dedicated to providing that abstraction. Equally nosql would be possible.

DM

Quote from: DangerMouse1981 at Jun 18, 2011, 06:56 AM

Interesting comment RE nosql implementation.

The use of XPDO is one of MODXs biggest strengths, but also its biggest weakness. Essentially reinventing the wheel where ORMs such as Doctrine 2 hold a stronger position. For example, the upgrade to enable MSSQL wouldn’t have been an issue if MODX was based on a library dedicated to providing that abstraction. Equally nosql would be possible.

DM

The new generation of noSQL storage servers are great tools for certain things, just as relational databases are. They are designed for very different purposes and when used properly both can provide some amazing solutions, usually together. There is also a place for both in the MODX world, but to assume that xPDO is a barrier to this abstraction is naive. xPDO is divided into domain and table classes already, providing the simplest and purest abstraction for any storage engine to be used where the table classes are. You can rest assured that xPDO is a library dedicated to providing the abstractions necessary for the success of MODX.

I also believe this author is using old arguments against ORM and the writing on it is neither fresh nor particularly insightful. Doctrine 2, was not functional when this project was started, and IMO, would be a barrier to the needs and successes of the MODX framework even now. There was no re-inventing of wheels in xPDO; there is no other framework that does what it does as efficiently. xPDO does not require it’s own DBAL or query language to function (speaking of wheels). I also guarantee you implementing MODX on MSSQL (or even MySQL) using Doctrine would have been just as much of an issue (if not more). Being unnecessarily dependent on the separate goals and needs of that project has never made sense in our view.

Argh
well i ’m think i am too old for these feature, for me i love sql , it was freedom for a lot of programmer which were obliged to make program for any question of end-user before the sgbdr. ( you know the data which is demand one time for yesterday ... )

Sql was created for end-user american when we have only text interface , don’t forget that .

Sql permit to extract information without need of programmer ( i know persons which are excellent sql users and not at all programmer )
Some programs like Bi-query and business objet permit to do this more easily for all end users.

For me storing objects is a bad thing, it is data which is important.

If your goal is respond to answer of end-users like ’ give me all products not selling more than 100 or less than 10000$" then SGBDR is excellent and you must construct your model data for questions not for objet to create data.

Now for modx i don’t know : thinking object for ressources, chunks, templates and not data relational maybe but not sure but for data products associated or anything else not sure ...

Sql is easy to understand and type to an console sql (perhaps no for no english native langage) but it is not efficient to programming i agree, xpdo is very excellent to programming.

What i say that ? because in beginning we make more programing to store data but data was easily questioned.

Now we need 2 databases : one for storing and one for questioned and the night a cron job transform database store (object) in database questioned (relational ).

maybe nosql is good for some project but not for all, and not for modx i believe.

xpdo for me is fine for programmer ( maybe it lack a langage like this in sgbdr for programmers ... sql is really an end-user language for me but not adapting for programming is true)

---

Arialia an old woman coder which begin with Cobol in 1990 ...

After doing a bit of research, I found that "nosql" is actually a catch-all buzzword for several non-relational technologies. I think that it will be some years before any of them become as used as the SQL relational-based variants, though. Kind of like the eventual death of table-based sites, the "old-school" has to fade away somewhat first, as well as the new technologies becoming more understood and friendly.

The current state of SQL/OOP/ORM etc. etc. reminds me of something I read about XML, "if XML doesn’t solve the problem, throw more XML at it".

However, I was happy writing 8086 assembly language utilities on Edlin, so what do I know?

The name NoSql is rather misleading. I prefer the term ’structured storage’, while it’s not really perfect either.

There are ideas to create a common API for all those DBMS’, but I would prefer to extend the established, as mentioned in my former post. It worked with programming languages (C -> C++, Pascal -> Delphi, Basic -> VB -> VB.net), why should it not work with SQL in a similar way?
I know, the comparison is not exactly sound. But it suffices to describe the direction.

The biggest problem with SQL is that there is no standard, or at least there is supposed to be a standard but no one uses it. Every implementation has their own proprietary non-compatible versions of too many of the basic operations.

One would think that the years of aggravation over character sets and core language constructs for just about every programming language ever devised being "extended" by every vendor would have impressed the need for standardization, with the variations between vendors being in internal optimization of said standard constructs, but no, every vendor has to try for a lock-in to their own products.

We have the extreme example of Microsoft and Internet Explorer and their particular (and peculiar) implementation of HTML, CSS and Javascript, with every version having its own incompatibilities with everybody else and even with its own earlier versions.

While the incompatibilities in "standard" SQL may not be quite as extreme, just try making a simple switch from MySQL to SQLite when you have something as basic as a few joins. Good luck. Of course, MSSQL was based on Sybase so those two are pretty much compatible (and as usual, MS got sued by Sybase for ripping off more code than they contracted for), but between MSSQL and Oracle any attempts at a port will be a major headache.