Yeah, but the relational model is terrible for representing graphs, no matter the tools you use, you are still bound by the representation you choose in a relational database.
What I like about AR is precisely its close correspondence with a relational database. Objects have create/save because they correspond to DB-tables and that's not something I want to forget when working with such a database. Personally I want to control when a specific object gets persisted, as to me that point is crucial, both for performance and for data integrity.
When the relationships between tables get too complex, that's a good time to reevaluate your data-structures and how you process that data -- as in, do you really need a live graph inside your requests, or will a pre-processed view will do, while having hooks for inserting new data and rebuilding your models asynchronously (on a single thread to avoid race conditions)?
Also, there are some databases around that are specialized on storing graphs. Even if the relational model is very general-purpose, sometimes you're better off choosing a system that's more suited for your goals.
a mechanism for dealing with situations where
someone change data underneath the object graph
a user is working against in memory
I kind of understand what you're saying, but you should avoid sharing of resources like that. Choose stateless requests, even when building non-web apps.
Do not let users trip over each other and if you do, construct a trail of actions taken to be able to Undo (as in, the Command pattern).
It clarifies for me that the goals of Active Record and other forms of ORM are so different that it's misleading to categorise them together. Active Record presents a simple and unambiguous interface to the way things are, [other systems that I don't have a noun for] try to abstract it away.
The way we use databases is interesting. In the early days of computing, a lot of the low hanging fruit was reached via software that wrapped databases. As a result, the database tools reached awesome power, maturity, and mindshare. As a result, they now get used for things well outside of their domain.
I suspect there are patterns that get squeezed out by this, and it's a topic I'm interested in exploring.
What I like about AR is precisely its close correspondence with a relational database. Objects have create/save because they correspond to DB-tables and that's not something I want to forget when working with such a database. Personally I want to control when a specific object gets persisted, as to me that point is crucial, both for performance and for data integrity.
When the relationships between tables get too complex, that's a good time to reevaluate your data-structures and how you process that data -- as in, do you really need a live graph inside your requests, or will a pre-processed view will do, while having hooks for inserting new data and rebuilding your models asynchronously (on a single thread to avoid race conditions)?
Also, there are some databases around that are specialized on storing graphs. Even if the relational model is very general-purpose, sometimes you're better off choosing a system that's more suited for your goals.
I kind of understand what you're saying, but you should avoid sharing of resources like that. Choose stateless requests, even when building non-web apps.Do not let users trip over each other and if you do, construct a trail of actions taken to be able to Undo (as in, the Command pattern).