(= 'ORM 'OMG) #Clojure
What ORMs have taught me: just learn SQL (2014)
151–160 of 305 posts
Re: What ORMs have taught me: just learn SQL (2014)
#152Earlier quoted context omitted.
This is the sweet spot of ORMs. A team lead early in my career wrote a tool that read the database schema and generated all the marshaling code at the application layer. We got a degree of type safety and relief from a lot of boilerplate code but no promises of automatically generating SQL or abstracting away the database schema, etc. It worked so well that I wrote one from scratch in another language a decade later…
We released a tool, xo, that generates safe and idiomatic Go code from a database schema that does not make any use of an ORM. I have been meaning to add support for generating code for other languages but have not yet had time to do that. That said, it is very easy and very straightforward to do so. Check it out: https://github.com/knq/xo
xo is great, we've used it a few times for existing databases, great timesaver. Thanks!
Re: What ORMs have taught me: just learn SQL (2014)
#153Earlier quoted context omitted.
To be fair, I've never seen a large project be anything other than a giant mess. This is the nature of large projects. If it's not a giant mess, you are probably leaving user happiness (= $$$) on the table.
And it comes at the expense of craftsmanship and programmer happiness. Lately I've been thinking how much initial architecture affects the mental well-being of all subsequent programmers that join the project. This is one of the reasons there is such a high turn-over and burnout rate in programming. If you're not consistently paying back technical debt and improving the architecture of the project then you're paying…
All this is true, but it's also the reason why programmers are paid as much as they are. In general, in a market economy, you are paid to do things that other people don't want to do. The whole point of a market is to create an incentive to do things that are unpleasant.
Beautiful code does exist in the software world. It's usually found in hobby, open-source, and research projects without profit motives, userbases, deadlines, and all those other complications that result in shitty hacks.
In the meantime, you could look at the crap that is most large-scale codebases as a barrier to entry that keeps demand for programmers high. Enjoy the money you get for cleaning up other peoples' messes, and then use that to buy time to make the beautiful, useless stuff.
Re: What ORMs have taught me: just learn SQL (2014)
#154Earlier quoted context omitted.
At the big tech firm I work at, there's a best practice where any database (whether that's a traditional RDBMS or a NoSQL client) is abstracted away by a microservice with a defined API, and every other application that wants to get that data needs to interact with the microservice. That way, the database schema can change without it affecting multiple applications. There's still the traditional mismatch between ORM…
We have decades of research into filtering, joining, and aggregating across a complex set of tables and views. With microservices you have to roll your own query planning and stream all the intermediate results on the wire even when you're throwing away most of them.
Unfortunately, SQL servers aren't generally scalable. Offloading joins and aggregation onto (inexpensive) app servers can increase over all system performance, despite lack of advanced query planning.
Re: What ORMs have taught me: just learn SQL (2014)
#155Earlier quoted context omitted.
> If you write some code, then you have just written an ORM. What? No, I've written code to query a database. Not an Object-Relational Mapper. my $q = $db->prepare("get_my_stuff_by_name(?);"); $q->execute($name); or with fancy metaprogramming: use DBMagicStuff 'postgres://…'; get_my_stuff_by_name($name); That's not really an ORM.
You are both partially right. An ORM deals with the black magic of connections, parameters, transactions, etc. If you don't use an ORM, then you still have to deal with those semantics. But I do agree that you aren't writing an ORM.
> connections, parameters
The database driver takes care of that, not the ORM.
(It's also not black magic.)
> transactions
Huh? That's a database feature. BEGIN/COMMIT/ROLLBACK are ANSI SQL.
ORM is an _Object Relational Mapper_. You're confusing it with a database driver (or, in the case of transactions, just a database in general).
Re: What ORMs have taught me: just learn SQL (2014)
#156Earlier quoted context omitted.
Unfortunately, ORMs sometimes undermine safety for the sake of convenience. Even ORMs which use parameterized queries (which any sane framework will) may be vulnerable if they build dynamic queries using string concatenation.
No ORM will pass queries using string concatenation? (Right? I know nothing about ORMs written in PHP by beginners that don't know SQL if it jumped up and bit them in the ass... But surely no half-decent ORM would concatenate strings to pass arguments?) Anyway. Type safe queries like QueryDSL is extremely nice to work with. But as was mentioned, it all boils down to this: There IS NO silver bullet. You have to learn…
> But surely no half-decent ORM would concatenate strings to pass arguments?
I wish... Drupal had an issue in ORM itself. https://www.drupal.org/SA-CORE-2014-005
Re: What ORMs have taught me: just learn SQL (2014)
#157What reading articles on how bad ORMs are has taught me: More people need to use Django. Django does a lot and does it well.
I wouldn't say the ORM is Djangos strongest point. Its great for simple stuff, but not great for any moderately complex queries (e.g. extra conditions on a join, subqueries, conditional aggregates - though I think that last one may be solved in the most recent version). I don't think they have done a bad job with the ORM, but you really ought to know SQL as well.
I think the ORM is Djangos strongest point. Take the ORM away and then ModelForms and Admin go with it. I think Django makes little sense if you're not using the ORM.
That said, you're absolutely right that it is really bad at certain types of queries. There's no way to really influence joins. Subqueries are coming (https://github.com/django/django/pull/6478), and conditional aggregates became possible in Django 1.8 with Expressions support (which I authored). Queries that map over many to many relations that have .exclude() or .annotate() generally produce incorrect results. Most of the problems with the ORM are as a result of Django handling joins for the user - which is also one of its biggest strengths.
You should absolutely know SQL if you're using an ORM. If you're doing anything other than basic CRUD, you have to know SQL. An ORM should give you an escape hatch to write that custom SQL. Django's ORM does not save you from all the problems mentioned in the article.
Re: What ORMs have taught me: just learn SQL (2014)
#158SQL is a write-only language. You better hope you don't have to rewrite your complicated raw SQL queries in the future.
You can write well written modular SQL that supports changes and can be read by a competent developer.
If you do SQL full-time probably yes. The problem is that most developers don't work enough with it so their skills are lacking.
Re: What ORMs have taught me: just learn SQL (2014)
#159Earlier quoted context omitted.
Not in my experience. Please show me actual examples of "well-written modular SQL" in a real application.
Would modular sql be wrapping up subqueries inside of views, and then selecting from those views?
Common Table Expressions (CTEs) help with modular SQL.
Re: What ORMs have taught me: just learn SQL (2014)
#160Sigh. Whenever I have to hurt myself at work on such issues, I find myself thinking of the web that could have been, if only... Let me backtrack a bit. There's a much better way to do things than the way we do it right now. A way that completely obviates the need for ORMs, or indeed any way to deal with the interface between application and database. You see, there would be no object-relational Impedance Mismatch (an…
This sounds really interesting, but I'm having a lot of trouble trying to follow how all that code fits together - from what code I could find. I also strongly dislike the object/function based approach to constructing HTML (which - funnily enough, is just like using an ORM to construct SQL which I like heh).
Really, I don't see enough offered to counteract what little pain I feel using an ORM. The LP actually looks more painful (to me). Obviously I'm totally unfamiliar with this stack which makes it hard for me to see where the benefits lie.