W liście MilesTogoe z dnia środa 21 stycznia 2009: > chris mollis wrote: > > Agreed.. data persistence should never be tied to the domain model. > > That's precisely the problem with ActiveRecord (sic Django/RoR) > > whoa, first Django and RoR do work for thousands of people / sites. > The question is can something else work even better? The goal is what > is productive for users and still produces a responsive data model.
Actually yes, there are things that can work better, eg. SQLAlchemy or Hibernate. I don't know much about Django ORM, but pretty much about RoR ActiveRecord. Such a simple ORMs have many limitations, eg they assume one table - one class. What about join-table inheritance? What about a db structure when one object maps to three tables? Or one table to many objects (the last one is supported in RoR actually). What about vertical and horizontal partitioning? Similarily, they usually lack an identity map. When doing really complex operations it is very probable you'll end with two object instances that represent the same row - and it'll be a pain to solve. Original poster mentioned situation, when he wants to switch from RDBMS to another storage mechanism. Now, if that mechanism (eg files) requires some objects to be kept together in one file... let's say a blog post and all the comments in single file (stupid example, but will do for now). What about all the calls to comment.save()? Should they just do post.save() or not? Will that mean you save a single post many times in a single transaction? Another thing, not strictly related to AR... code written with such a ORM tends to put too much logic in persistence operation hooks, like before/afterInserts, before/afterDelete etc. In the end, it's usually a bad idea - those methods should just deal with persistence aspect, like data denormalization - not even logging (I'm planning to write a post on that later). ActiveRecord works pretty well for simple schemas, but as the schema and application logic grows, it becomes more and more difficult to use properly - I mean applications where transactions span multiple classes, eg receiving CC payment triggers checking customer account balance which fires multiple no-longer-debtor hooks which re-activate customer's internet account which allocates IP in the network which determines the pool is 90% full and sends an e-mail to network operators etc... Fun starts at 100 tables in the system. Cluttering domain logic code with persistence aspects is not nice. -- Paweł Stradomski --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
