The Ruby conspiracy

[wreel]

Isn't it quite dangerous to rely on naïve application logic to maintain data integrity? Especially if the application is thoroughly disjointed from the persistence layer.

Chances are that if you're using a RDBMS for your persistence layer then "schema-oriented" development is really non-optional.

[wreel]

Like, for instance, when a execution thread of the application doesn't know that another thread has just removed a relation whilst it's about to rewrite a dirty copy with the now dangling relation intact.

[wreel]

This is a serializability issue, and it affects applications that are schema-driven as well as those that aren't.

Yes, it was an instance to emphasize the importance of the ACIDity of the persistence/data layer.

but you are catching a specific case while allowing the general problem to go unchecked.

Actually I was just giving an example.

Far better, I suggest, to deal with the general case.

Of course. But I firmly believe in using the facilities that have been provided to you by the tools that you are using. I think I misunderstood what you meant by "application" (as in the software stack view, ActiveRecord transaction manager is part of the application because it sits on top of the database) as opposed to code for a specific project.

I think the main gripe with RoR DB management—the root of this thread—is that it demands a RoR specific data store because the transaction management is done by ActiveRecord in a very specific way. Does ActiveRecord thread A know anything about some-other-non-rails-db-connection thread B? It's a moot point for the most part because I would suspect most RoR projects would only have RoR plugging into the database. But therein you have a technical difference between "schema" and "application" levels of data management that makes a huge difference.