3 ms·
Right, so an ORM makes the easy things easier. The hard things are either harder or you need the escape hatch. I've both created an ORM (long ago, back in Java
by geophile 11y ago
Right, so an ORM makes the easy things easier. The hard things are either harder or you need the escape hatch.
I've both created an ORM (long ago, back in Java 1.0 days) and used a few. My conclusion is that the real pain in interacting with a database isn't writing SQL, it's managing the API (e.g. JDBC). Managing PreparedStatements, managing ResultSets, handling exceptions, getting rid of warnings, mapping to objects (if that's what you want), extracting each field and converting appropriately, binding parameters (again, with appropriate conversions).
I eventually decided that my ideal ORM just managed all that crap and let me write the SQL. (Of course, it's only approximately 0.5 of an ORM at that point, but I don't care if it no longer deserves the title.) It did the book-keeping, and let me focus on 1) the application (written in Java), and 2) the SQL. I then discovered that iBatis is based on this idea, (I think the name is slightly different now).
- kibibu 11y ago> Right, so an ORM makes the easy things easier It certainly makes migrating from MySQL to Postgres a lot easier.
- icebraining 11y agoI guess it depends on your needs. On the platform I work on, the user can configure a set of security restrictions on tables (e.g. users of group 1 can only read records of table X which have public = TRUE; users of group 2 can only update records of table Y which have user_id = [their own user id]), and the ORM automatically inserts those restrictions into any query made to those tables. Doing this with manually written queries would be, if nothing else, a PITA. Then again, it's a specific need; I suppose most applications have static, not dynamic rules.
- geophile 11y agoIt sounds like a VIEW would handle this restriction also. And then you should be able to use any ORM or lower level of abstraction.