4 ms·
ORMs are nice for simple things, but once you get to a system with a decent amount of complexity they really start to fall down. Case in point, doctrine has a c
by CitizenKane 16y ago
ORMs are nice for simple things, but once you get to a system with a decent amount of complexity they really start to fall down. Case in point, doctrine has a custom query language to deal with a lot of the complexities. This is actually the reason behind the slowness you pointed out.
Thankfully, there is the entity system which for all practical purposes is an ORM on steroids. It abstracts storage away from the developer, has attachable fields with per field storage configuration. Plus every entity has a completely customizable controller class. There are now modules that give you an entire controller architecture (http://drupal.org/project/entity http://drupal.org/project/entity). I think it's a pretty cool idea and blasts ORMs out of the water.
- stdbrouw 16y agoI'll take anything over the pre-7 approach of either extending nodes, trying to wrap your head around programmatically using CCK or doing plain SQL... but an ORM on steroids? The code samples on http://www.istos.it/blog/drupal-entities/drupal-entities-part-3-programming-hello-drupal-entity http://www.istos.it/blog/drupal-entities/drupal-entities-par... aren't exactly what you'd call elegant, bundles are a poor man's inheritance, you need a contrib module (Relation) to do something as basic as relations, and EntityFieldQuery doesn't even come close to the expressiveness of e.g. SQLAlchemy. It's an enormous step forward, but don't get cocky :-)