3 ms·
> For example, in the platform I use, when I "fetch" some records by ID, it doesn't actually issue a SELECT; it just collects the ID and returns a proxy object.
by GrinningFool 10y ago
> For example, in the platform I use, when I "fetch" some records by ID, it doesn't actually issue a SELECT; it just collects the ID and returns a proxy object. Only when I access an attribute of that object, it'll issue a SELECT for all the IDs in question.
I'm my opinion this is the least desirable behavior. It abstracts the data layer away to the point where you don't think about what's happening under the hood when you type foo = Klazz.new("id"); foo.bar; foo.baz;
Was that one, two or three separate queries ? Did a query run at all? Does it matter, after all you have an object to work on, right in your language of choice.
Sure the ORM may be smart about it and do the right thing - I have no doubt that most decent ones day. But that misses the point - as the person using this interface you get divorced from the direct awareness that this data has an origin, and there is a cost to access it. After all, you're just instantiating an object.
Patterns that use interfaces that make it so simple to do a thing that you don't need awareness that you're doing it tend to degrade quickly after the original engineers who did have that understanding leave a project.
- icebraining 10y agoThat's a fair point; on the other hand, aren't SQL queries themselves divorced from the actual data layer? Knowing whether the ORM issued one or two queries doesn't tell you if you're fetching data from disk or memory, whether it's making an index scan or full table scan, whether the join fits in working memory or will hit the disk, etc. Isn't knowing what queries are issued giving you a false sense of knowledge about how the data is actually fetched? And much the same way you can request a query plan, the ORM could provide the list of queries issued for a given piece of code.