Re:Show HN: Firestorm – An ORM for Firestore
by nine_k on Sunday August 25, 2019 @09:48PM
(#20796899)
I would say that ORM, as presented by ActiveRecord and similar approaches, is an anti-pattern. Serviceable in simple circumstances, though.
Such ORMs pretend that data are objects in OOP sense, with internal mutable state stored in their fields. This leads to endless bugs with dirty vs clean state, complicated and bug-prone logic in `.save` methods, hard to debug performance problems with transparent lazy-loading of related objects, and inevitable performance loss on hydration / dehydration of all fields. (I saw and fought this all in practice.)
Better approaches, such as the one available in SQL Alchemy, do not hide the relational nature of the data. They allow to `select` arbitrary tuples, and, most importantly, to build queries from composable, reusable parts.
ORM is not the best interface to an RDBMS. But a good, ergonomic interface to an RDBMS is a very important and useful thing.
Such ORMs pretend that data are objects in OOP sense, with internal mutable state stored in their fields. This leads to endless bugs with dirty vs clean state, complicated and bug-prone logic in `.save` methods, hard to debug performance problems with transparent lazy-loading of related objects, and inevitable performance loss on hydration / dehydration of all fields. (I saw and fought this all in practice.)
Better approaches, such as the one available in SQL Alchemy, do not hide the relational nature of the data. They allow to `select` arbitrary tuples, and, most importantly, to build queries from composable, reusable parts.
ORM is not the best interface to an RDBMS. But a good, ergonomic interface to an RDBMS is a very important and useful thing.