In these cases, I’ve elected to write queries using a templating system and describe the tables using the ORM. I get the convenience of an application level description of the table with direct use of SQL. It’s a lot less trouble than anything else I’ve used so far. I was with the spirit of the article save for this. Recently I've been developing some work for one of my client's in the .NET world. There had been ongo…
Make it a product and sell it/github it.
What ORMs have taught me: just learn SQL (2014)
521–530 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#522Earlier quoted context omitted.
>You can (and should) use them for simple queries. This is not a very compelling argument to use ORMs. It is saying "it makes easy things easier". This doesn't really buy you much value. The simple things are already simple. Bringing in a very large, complicated external dependency to make simple things simpler, is not a good idea. >If you're loading data into objects then you're just creating your own personal ORM a…
> It is saying "it makes easy things easier". No it makes simple things easy. Simple things in raw SQL are bloody complicated. Even just getting data, manipulating it, and saving it is at least twice as difficult in maintainability and lines of code than using an ORM. > An ORM converts one paradigm into a completely different paradigm, which is why it fails and is a terrible idea. I'm not sure where people get the id…
That has not been my own experience outside of the most trivial queries. Once any amount of complexity is introduced, I find that ORM-based queries often make it difficult to really see whats going on with indexes and locking, I can’t just paste a query (eg to use EXPLAIN) without finding it in a query log first and, unfortunately, in my experience its rare to find teams disciplined enough to not treat ORM code as if it were normal application code (ie don’t mix it into your application logic), so often end up with a few database/application roundtrips, doing filtering in the wrong place etc. Yes that last one isn’t technically the fault of the ORM, but when I see it again and again in real world code, I start to think that most developers don’t have the discipline to be careful with ORM code while when not using ORM’s and writing raw SQL outside of your applications code, you have no choice. Not the ORM’s fault, but still a symptom of using one that I’ve experienced in multiple teams.
Re: What ORMs have taught me: just learn SQL (2014)
#523Earlier quoted context omitted.
Python doesn't have type safety to begin so those sort of checks have less utility to me and since json.loads returns a dictionary and python objects are effectively dictionaries you are pretty much done.
You don't validate incoming request types / values?
For example if I'm going to use a value in a query, because I'm using parameterized queries the type conversion to string happens implicitly so type doesn't actually matter. If I get 2 or '2' it all ends up as '2' and the database infers type by the column type.
If I need something to be a integer and I don't trust the upstream system then you have to:
int(*number*)
At the end of the day if my JSON is going back to JavaScript I can't trust types either so I have to take the same precautions.Re: What ORMs have taught me: just learn SQL (2014)
#524This 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…
Hahaha! ^_^ Seriously Jesse, isn't this the very same reason __some__ people end up implementing yet another programming language without realizing it? First they start out of exasperation with X language they use, because they hit some obstacles or limitations, and before they know it they end up implementing a newly created language. You know what's the fun part? In their attempt to fix the aforementioned language'…
Re: What ORMs have taught me: just learn SQL (2014)
#525Earlier quoted context omitted.
This is correct. An in-house solution is a solution developed in-house for your specific problem , which no one else has ever had exactly. The more specific the need, the more the benefit of the made-to-measure solution. The alternatives are something your organization didn't develop, which may be better, but you don't know how to use it, or may be worse, but you don't know that when you pick it, or may be slower, bu…
Isn't this an argument against using any library at all?
Which bring us to the topic of tradeoffs and the synthesis of balance, by way of weighing competing advantages and costs fairly.
On the one hand, code you must write and understand. On the other, code someone else wrote, that you can just use. There is no clear winner here. It's always a tradeoff.
Re: What ORMs have taught me: just learn SQL (2014)
#526This 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…
I have the opposite view. I find ORMs annoying and obscure, and I think they introduce duplicated code. If you need to run a certain query in multiple places, you need to repeat the same ORM expression or refractor it into a function. I find much better to have a module with all my SQL queries as strings. That way whenever I need to run a query I reference it from there. Of course it helps to use meaningful names. Th…
Composing SQL expressions using this library instead of using string interpolation/concatenation has several advantages:
* DRY and composition * safety * portability (if you have switch the underlying DBMS)
Often the result is as good or better than my raw SQL. The fact that Python has an amazing REPL makes the process pretty much like testing queries in the database prompt but with less cognitive switch between languages.
In the end it is a matter of taste, but I have to agree with parent posts, SQLAlchemy raises the bar for other ORMs.
Re: What ORMs have taught me: just learn SQL (2014)
#527Earlier quoted context omitted.
Python doesn't have type safety to begin so those sort of checks have less utility to me and since json.loads returns a dictionary and python objects are effectively dictionaries you are pretty much done.
> Python doesn't have type safety It does, if you want it to, with several typecheckers available.
Re: What ORMs have taught me: just learn SQL (2014)
#528Earlier quoted context omitted.
ORMs that I've experimented with tend to fall into one of two categories: either they treat the object model as prime, or they treat the relational model as prime. The former almost invariably spurt out inefficient queries, or too many queries, or both. They usually require you to let the ORM generate tables. If you just want to have your object oriented design persist in a database, that's great. The latter almost i…
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…
Re: What ORMs have taught me: just learn SQL (2014)
#529I too have gone back to SQL after working with ORMs for 10+ years. Having worked with them on a wide range of projects and teams, I can say, without any reservation, they are not worth it. Not worth it for the small projects nor the large projects. They significantly complicate the development workflow and add another layer of (often times, cumbersome) abstraction between the user and the data. If you encounter any i…
I've ripped out broken ORM on multiple projects with over-engineered domain models designed by people with no apparent knowledge of how to do a proper database design. This is the key problem with ORM. It leads to lots of unnecessary joins just so you can pretend databases do inheritance or all those tiny objects you will never query on need dedicated tables with indexed columns. It's stupid. It's also stupidly slow,…
I understand both points of view, with ORM saving my brain from writing massive JOINs on multiple tables yet at times forcing me to dissect a ORM query because it's doing something stupid. But if I didn't use ORM I would have probably not even made those stupidly complicated tables that I have to debug in the first place. Maybe even worse, is that instead of learning SQL I had spent all my time learning the ORM's API.
It's a balancing act, with good points on each side. I like writing my own SQL, I think it makes me think harder what I'm doing. Sure then I'll be probably writing my own helpers that might resemble a half-assed ORM but as long as it is kept simple, outside of the hands of those who wish to over-abstract everything with their fancy design patterns, it should be highly efficient and easy to understand. And the best of all, my understanding of SQL will be a lot more useful than knowing some language-specific ORM.
Re: What ORMs have taught me: just learn SQL (2014)
#530Earlier quoted context omitted.
So, SQL is the shovel, correct?
The typical language people use is imperative language where you state how to do something, while sql is a declarative language where you say what you want. Since we are in the world of analogies, using an ORM is like taking a shovel and using it as a prop (without speaking) to explain excavator operator where to dig, how deep, how wide, what things to avoid etc. Except querying a database can be much more complicate…
The mindset was correctness and validity of a detailed and interrelated collection of known facts, at rest on disk.
Merging 2 of these, say when an insurance Corp buys a competitor, took detailed and painstaking effort by people with both the domain and systems knowledge.
It's very different now,with Json doc stores, where in 5 years time noone will know what timezone that happened in, or if this person is that person with different name because of lossy utf8->ASCII .