i'm not sure if ORMs are an anti-pattern

i'm not sure if ORMs are an anti-pattern 

 

i like to deeply understand every abstraction i'm using, and I see a lot of unanswered questions about ORMs. 

 

- is orm an anti-pattern? http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern 

- if we want object abstractions on our data, why aren't we using an object database? (relational constraints, joins, transactions) 

- if we need joins or transactions, is thinking in terms of objects harmful? what would a data-oriented (rather than object oriented) system look like? http://gamesfromwithin.com/data-oriented-design 

- besides object-oriented and data-oriented, are there any other ways to think about our data? what would it look like if the object-relational mapping layer were specialized on a per-object basis? 

- why exactly is pseudo-sql or a conditions API really necessary 

- what should a conditions api do or not do, especially with respect to mutating queries 

- should a conditions api handle paging? 

- case study of existing conditions apis, good ones and bad ones, what are the design tradeoffs, what are some design mistakes -- http://engineering.foursquare.com/2011/01/21/rogue-a-type-safe-scala-dsl-for-querying-mongodb/ 

- its convenient to have an object representation of our conditions so we can traverse a tree to mutate them, but is this a good idea? if we thought through the problems, couldn't we pivot the control flow such that we can functionally decompose the condition creation such that we don't need to mutate state? 

 

i think these are hard questions, and i don't have the answers, but a group study would be cool. but there is significant homework to be done first. i'd rather somebody more qualified steps up, but if not and there is interest i may be willing to lead the discussion.