The biggest issue with Orms is that they lie

0 Vrms?

ORMs are one of those things that sound like a really great idea on paper and then become the biggest pains in the ass imaginable

@12bitfloat oh, shit, lol

The biggest problem with ORMs is that most devs think they’re amazing and thus use them excessively, especially when and where they shouldn’t.

The biggest issue with ORMs is that they work well until you add the first bulk update or arbitrary SQL query, which usually happens too far into development to remove every reference to the - now permanently unreliable - caching layer.

You can map a remote object to cached rw local objects if you can guarantee exclusive write access. Otherwise writes should be commands that are asynchronous, fallible, and failure or success is determined before the local object - which may be shared - is updated with their speculative outcome.

The biggest issue with ORMs is they solve a problem that shouldn’t even exist.
Not every use case needs a relational database.
Use a nosql db and you don’t need fucking ORMs.

@Lensflare I mean even then, unless you're using javascript, I can understand the want for a layer that translates your native classes/objects into sql

The problem is that sometimes you'll get a little more than you've bargained for with these abstractions...

@Lensflare the issue shouldn't exist bevause sql is very decent and people should be less scared for it. I use py dataset mostly, it's a zero config adapter making you use several sqlite databases as document store by doing automatic schema migrations. Field type equals your first input value. Not sure whet it does when it's null tho but it doesn't matter much since I use sqlite mostly as backend. With asyncio in combination with dataset (not being an aio lib) I have made a live chat application that can send thousands of requests in seconds. Way more, but it's rpc that waits for a response before it will execute next command. So, server very async, client not so, but don't see a benefit in that anyway. Calling is sync, teceiving events is async. So my chat app receives notifications / events instant. I gonna implement the live upload status of files from a user to other users. It won't feel it even, it keeps working regardless how hard you benchmark it.

@12bitfloat even for the sake of auto completion or the guarantee it gives that your object can be inserted. It's kinda like compiled code, most critical checks are done. Also it's comfortable to add custom sub queries for related objects, formatters, validation. In my project validation is done on models and there's one single point of truth regarding input data. So the form class and frontend both rely on the model validation. Orm has much advantages, especially if you build yourself. It's easy but ofc just use the query function for sql if needed. The weird stuff I've people see doing just not to do that and trying to solve with orm.. Omg.

@retoor it’s about using the right tool for the right job. SQL isn’t always the right tool and I suspect that there is a shockingly large number of devs deciding to use sql by default, not even thinking about if nosql makes more sense or not.

@lorentz the problem is: if you're using an arbitary SQL query, you're bypassing the ORM itself. you can't blame a tool for not working properly if the reason is that you're not using it properly.

@tosensei you surpass the mapping part but I do this with resulting in models. Still use the model part. So I have some complex where and joins to list some objects, but use the same models so application doesn't care at all.

@Lensflare I always thought the other way around, people not able to think abstract think that a documentdb is a solution for that. Everything has a hierarchy / structure. Same for OO. Just sql for management is most comfy every. Sql is made for managers, nosql for devs. Sql is obviously easier.

@retoor yes, everything has structure and nosql doesn’t mean no structure.
A nosql db will actually better reflect the structure of the data in code because in code it’s a hierarchy or a graph and sql can’t have hierarchies or graphs. Sql is relational and expresses hierarchical relations via data, not structure. You need to introduce extra tables to be able to express relations between entities which are organized in graphs or hierarchies.
The main point of an ORM isn’t just bringing the db entities into the code, but mapping the relations (it’s in the name ORM).