3 ms·
No you dont. Sorry for the blunt answer. ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)
by cies 2y ago
No you dont. Sorry for the blunt answer.
ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)`), they do not help you for hard queries (ORM-using codebases of size usually have hard-SQL-queries "in strings").
Most users of FP langs know this and hence will not even try to implement ORMs.
Look into jOOQ, LINQ-method-syntax (or whatever it is called, without the funny SQLish syntactic sugar), SQLDelight or sqlx for non-ORM options that improve embedding SQL in general purpose langs.
- rafaelmn 2y agoI like the idea of F# type providers but last time I tried (two years ago) they were pretty shit compared to any mainstream ORM/alternative - has that improved ? Also ORM for simple row selects is a straw-man - their use case is deserializing, updating relationship graphs where they hide away a bunch of code. Should that code be hidden is a different question - but pretending it's there to save you from typing SELECT * FROM foo is kind of disingenuous. Editing graph data structures in most FP languages is just not compatible with OOP approach hence no ORM.
- jcmontx 2y agoMost of the time we do simple CRUD operations, I want this plumbing to be as straight forward as possible. Don't be patronising...
- Dansvidania 2y agoI am always confused by this wish. If the operations are simple, why the need for ORM?
- cies 2y agoAnd the notion of lazy associations, life cycles, clean/dirty, attached/detached, ... etc, etc. The book of Hibernate is thicker than the book for SQL. The only thing that works better in ORMs is "save". Just call save on an ORM managed object and it is saved, quite a bit harder in SQL.