Learn SQL, yes, and then use your ORM as a handy SQL generator library because life is short and you do not want to write that much SQL.
What ORMs have taught me: just learn SQL (2014)
421–430 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#422Earlier quoted context omitted.
But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives
An in house solution is almost always better than an external dependency
Idunno man, my day job working Rails code uses a custom mailer and job queueing system and everytime I have to work with it I really wish they'd used ActiveMailer and ActiveJob
Re: What ORMs have taught me: just learn SQL (2014)
#423This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…
Sometimes you just should live with duplicated code. It's OK.
No, it is not okay. If you need insert/update/select for every object/table that is way too much duplication. It becomes very irritative when the schema changes. There should be table meta data in such a case but one should also know what one is doing. Having no idea that under the water 14 joins are done is not a good situation either.
Re: What ORMs have taught me: just learn SQL (2014)
#424Earlier quoted context omitted.
I think you may have only experienced bad ORMs then? All an ORM needs is a mapping between database fields and object properties so a good ORM should allow you to separately define a mapping between your object model and relational model so you retain full control of both. > it encourages you to write too much data manipulation logic in code rather than directly in the database I find doing too much business logic re…
Whereas I find doing too much business logic related data manipulation not performed by the database to be an anti-pattern that creates significant risks with testing and a source of data bugs. My model of thinking is that any copy of data that isn't currently resting in the database is potentially stale; avoid round trips like the plague; get new data into the database as soon as possible. For me and the way I work,…
> My model of thinking is that any copy of data that isn't currently resting in the database is potentially stale; avoid round trips like the plague; get new data into the database as soon as possible.
Nothing about an ORM stops you from persisting data as soon as it is ready or updating the state from the DB to ensure consistency (or from using transactions).
> rather more often a question of whether I even want my data hydrated into a special object at all. I've come to the realisation that for the kind of work I do, data objects almost always end up being an unnecessary layer of indirection that don't give me any real benefits
Yeah, if you don't need to use objects than there is no reason to use an ORM. Knowing the right tool for the job is critical and Objects and ORMs are not infrequently used when they are not needed.
In my work, updates are rarely atomic and business logic is complicated and intricate. It is extremely hard know what data you will actually need and so it makes sense to pass around a complicated object that has all the potentially needed state. This also gives me the option to separate logic about when to commit/rollback from logic about what to persist.
> because every transform becomes an opportunity to write a method on an object and not a straightforward query.
For me, this is a plus, not a minus :). Methods are easier to test and re-use as part of a complicated business logic flows. They make it easier for me to manage when data gets synced with the DB without having to duplicate code.
> —and they change the way you think,
I am going to pay more attention to this and see where I may have made mistaken presumptions and used objects unnecessarily when I could use atomic updates or queries instead.
Re: What ORMs have taught me: just learn SQL (2014)
#425I used ORMs JPA/Hibernate in several projects/teams and the outcome is always the same: things always get messy and overcomplicated, few reasons : - they push developers to design super-normalized db schemas that look beautiful on paper but are horrible in practice - the average developer has a very superficial knowledge of how ORMs work and this often leads to bad code/performance - soon or later you will find yours…
Agreed! I've found JOOQ to be excellent.
Generally ORMs try to abstract away the database entirely. This is mostly fine for CRUD stuff where you really just want to persistently stash away something basic off host. If you could write perfect uncrashing programs you'd probably just keep them in memory.
As soon as you need to find things, especially based on their relationships, you'll need to be aware of what indexes you have available at least. Eventually you'll want to have control of the precise query
JOOQ lets you compose queries programmatically without really hindering you from producing any query you want but not forcing you to glue strings together either.
Re: What ORMs have taught me: just learn SQL (2014)
#426Earlier quoted context omitted.
But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives
There's a middle ground. Micro ORMs.
also implicit row mappers so one can still do the queries manually without writing all the oo glue
Re: What ORMs have taught me: just learn SQL (2014)
#427Earlier quoted context omitted.
Um, PL/PGSQL and et al for stored procedures exist, OOP is optional.
So? Stored procedures suck. There are good reasons they have never seen serious traction and are infrequently used to the point of being irrelevant.
Major international banks have entire payment systems implemented in PL/SQL. I’m talking 2-3kloc procedures and thousands of them.
Re: What ORMs have taught me: just learn SQL (2014)
#428Rather than having a full ORM, a SQL system that didn't put in variables by embedding strings would be useful. You can almost do this. SQL has variables, but they're more persistent than needed for this.
SELECT a,b,c FROM tab WHERE a=@mysearchkey;
result = sql->command("SELECT a,b,c FROM tab WHERE a=@mysearchkey;",
{"@mysearchkey": val })
Re: What ORMs have taught me: just learn SQL (2014)
#429Earlier quoted context omitted.
Eventually if you’re working with an object oriented language or if you have to convert the result to JSON, you’re going to have to convert one paradigm to another. Unless you’re programming in assembly, everything you do is being converted into another paradigm that is what every compiler and interpreter does.
You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. When I am using a high level programming language, it is merely helping me do things like manage memory. I am not constantly wishing I could drop down and work with pointers and so on. It is a foundational paradigm that builds on the top of the one before it. ORMs just present a differen…
There are plenty of scenarios in certain verticals where you need to control memory management like games and others where you need to program in assembly. Garbage collection is an incompatible paradigm where you need to control when memory is allocated and freed.
Back in the day when I was doing C, there were times when we just couldn’t get the speed we needed from the compiler. I wrote inline assembly. Does that mean C was unsuitable because it was incompatible with our performance requirements?
Re: What ORMs have taught me: just learn SQL (2014)
#430This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…
Views are another way to gain reuse.
As are stored procs, user-defined functions, triggers, scheduled jobs,.. SQL databases are programming environments, not pure datastores.