8 ms·
I have a lot of experience with the Django ORM, but no other. So I disagree with most points. The Django ORM does map pretty neatly to SQL (in my opinion), an
by bayesian_horse 7y ago
I have a lot of experience with the Django ORM, but no other.
So I disagree with most points.
The Django ORM does map pretty neatly to SQL (in my opinion), and especially Postgres. The migration tool is anything but "half-baked". And I have observed that beginners have an easier time creating Django models than dealing with straight SQL.
On top of that, the Django ORM mitigates most SQL injection attacks out of the box, without even requiring the developer to know about SQL injections in the first place.
And the ORM enables elegant code reuse by constructing query objects that can be used in Template logic, Form validation, generic CRUD, REST endpoints and more.
I agree that most ORMs don't help you with multiple programming languages. Though both the Django ORM and SQLAlchemy allow to customize a lot of the naming conventions and can be adapted to any legacy schema.
But then again: Is it even a good idea to access the same database from two codebases at all?
Some of the concerns about "ORMs kill the SQL-star" can be boiled down to a lack of a general understanding of relational databases in developers who learn to use an ORM before diving deeper into the philosophy of relational databases.
- jialutu 7y agoI used to really dislike django ORMs since I had a background in SQL and thought that ORMs are really constraining and not as flexible as just writing SQLs. However, recently I have come into the realisation that not everyone who programs knows SQL (woah, what a revelation right?), and the django ORM is a really nice tool to fill that gap for them with something they are more familiar with (ie python objects).
- bayesian_horse 7y agoIf you are using any language other than SQL, then you better have a way to convert SQL data to the appropriate data types of your language and vice versa. And it better be injection-proof and reusable. That's already at least half of an ORM right there. I think I know SQL fairly well, but I don't see how I could implement things like django admin, form validation, template views etc as elegantly on top of plain SQL. So I really don't agree with "ORMs are only useful for SQL-noobs".
- tus88 7y ago> Some of the concerns about "ORMs kill the SQL-star" This doesn't even make sense. It kills the SQL duds, stars are even more important to understand the convoluted SQL when the ORM isn't working as expected, and cases where the ORM can't handle at all (there are always some).
- Scarblac 7y ago> there are always some That's not my experience. In ~20 projects in this company, with pretty complicated GIS-related web apps, there have been about 4 cases where I need to create a raw SQL query because Django's ORM didn't do what I needed. Almost all the time, it just works.
- Twisell 7y agoWhen you say "pretty complicated GIS-related web apps" does it mean you perform powerful spatial analysis using PostgGIS extension over a few millions spatial objects OR is it more about fetching a handful of spatial objects for display/processing in web-mapping framework? Because for pretty obvious reasons in the first case you'd want computation on the back-end. Sure you can do a lot of spatial operations with python after passing through an ORM... but is this really more adapted than raw SQL & PostGIS? Genuinely curious.
- Scarblac 7y agoMost of the processing happens outside PostGIS, we often compute things with geometries from PostGIS to raster data that we don't keep in PostGIS. So our Postgis queries are mostly limited to filtering on a BBOX, or closest distance to a point. What users want to compute can be defined by users, e.g., "take all houses in the Netherlands as polygons, compare with a DEM of the Netherlands to find the lowest point of the house's contour, compare that point to a water depth raster to see if it would be inundated" is a computation a user could define in our GUI and the actual computation would then run in (Python) background tasks.
- 7y ago
- dariosalvi78 7y agowhy using an SQL DB if you don't know SQL?
- bayesian_horse 7y agoBecause web frameworks, mostly.
- pmontra 7y agoComing from Rails I think that Django's ORM is too complicated, like almost everything in Django and in Python. However I'm using Python, Ruby and Elixir in different projects and Ecto is much more complicated. It makes me want to write plain SQL as I did in the early 90s. Actually I'd be OK writing SQL. It's just inconvenient having to decode the results and handle migrations manually. I did plain SQL migrations before ORMs. That's not something I want to be back to.
- andy_ppp 7y agoEcto is just a dsl for writing SQL queries, not an ORM. It’s difficult to understand if you think it’s an ORM...
- udfalkso 7y agoThis. It's not harder, it's different. Takes some getting used to, but then you realize "oh it's pretty much just sql that returns structs" and you instantly hate every other ORM you've used prior.
- bayesian_horse 7y agoDjango's ORM is pretty complicated under the hood, but I suspect that this is not easily avoidable given the requirements. I also don't subscribe to the view that Django is too complicated. With other frameworks you end up implementing part of Django, and most of the time that will be worse in every conceivable way.
- neya 7y agoI'm not surprised about your comment on Ecto. Ecto takes experience and practice, but by the time you finish writing your 5th or 6th application, Ecto will be so natural that you wouldn't want to go back. Especially not to writing vanilla SQL.
- pmontra 7y agoThe problem with complicate things is that the second application never comes. I've got a customer that's been paying me to write a Phoenix application for the last two years. That's good but I'm not going to use Ecto in one of my own projects. So no Elixir if it touches a database. There are simpler alternatives to Ecto, maybe I'll use one of them but Ruby and ActiveRecord are good almost for everything.
- hugi 7y agoMy experience as well. I use an ORM that I absolutely love for most work (Apache Cayenne) and I use plain SQL where appropriate, like for complex reporting. The "ORMs are bad" articles usually boil down to "My ORM is bad" or "I tried to use an ORM where it doesn't really fit and now I believe all ORMs are bad".
- jannes 7y agoEven for "complex reporting" you can still use ORMs if you save your SQL query as a VIEW in the database. Then you use ORM for reading the output.
- nablaone 7y ago> But then again: Is it even a good idea to access the same database from two codebases at all? It's an integration pattern. It works in some contexts.
- ants_a 7y agoIf its treated correctly as a set of SQL language API-s with clear ownership and explicitly defined public/private parts. There is a reason why its often considered an anti-pattern, and it is a general lack of discipline in maintaining stable semantics and separation of responsibilities.
- nnq 7y ago...you're the ONLY person I saw with a good opinion of Django's ORM. I'm willing to accept you could be right in preferring it, but: Could you share some resources of using it properly for advanced use cases? Good cookbooks etc. For, it's always been a huge footgun, coupled with Python's dynamic nature, it's and endless source of bug after bug... Mistype a property on a model instance - no problem, no error, it will just not get saved to the db and data will be lost. Use progres native json and array fields - good luck running your tests on sqlite, the ORM that was helpful up to here just gives up and tells you "f u buddy, you're on your own". Need to write complex hand-coded-sql queries that return complicated data, but you's still want to be able to serialize them into a graph of objects that can then be modified by regular ORM code - good luck with that, nobody cared about this scenario. They've somehow managed to make it too simple and too complex at the same time! Oh, and don't expect to just click a few jump to definitions an make sense of the ORM's inner code easily, god forbid :|... While I like the idea of ORMs, I found them all totally "wrong headed" And SQLAlchemy - that's just not worth the effort of learning to use it properly despite its good ideas, if you're only going to end up using 10% of its functionality and in an idiosyncratic way that was not intended.
- satyanash 7y ago> progres native json and array fields - good luck running your tests on sqlite you're not testing what you actually run in production, then what are you testing? If you just need to test in-mem behaviour, mock the DB completely; instead of expecting compatibility for vendor specific features across vendors.
- bayesian_horse 7y agoI'd say the sqlite backend and using it in testing is mostly useful for reusable django apps that are supposed to be used in a wide variety of projects. Most of the code I write in Django would never need to be SQLite-compatible, even if a lot of it would be. The SQLite compatibility is almost like a relict from a time when setting up RDBMSs was difficult and slow.
- 7y ago
- hyperpallium 7y ago> But then again: Is it even a good idea to access the same database from two codebases at all? A motivation for relational algebra was different applications accessing data in different ways. This integration remains a selling point. Further, data often outlasts applications... even languages.
- _visgean 7y agothe problem is that these days you need a lot of application code to check for permissions and that kind of stuff.
- dllthomas 7y agoIn principle permissions can go in the DB.
- bayesian_horse 7y agoIn practice this is rarely ever done (right). Row-level permissions are possible, but it can get more complicated when certain users are only allowed to change a certain row in a certain kind of way but not in another.
- dllthomas 7y agoI agree, but it does seem to become more compelling if you're doing your integration in the database.
- bayesian_horse 7y agoStill, I think accessing a single database in RDBMs like Postgres or MySQL from multiple codebases or even languages means asking for trouble. Providing some kind of API as a library, REST, RPC or whatever would almost always be preferable, if only to centralize permissions and validation.
- iamnotacrook 7y ago"Is it even a good idea to access the same database from two codebases at all?" Yeah, if you're migrating code between languages and platforms and want to run both simultaneously so you can go live with a subset in the new platform and phase out the legacy system in stages.
- bayesian_horse 7y agoIn that scenario there is no benefit to raw SQL because you might as well write the new Application with another/better ORM?
- iamnotacrook 7y agoNo rewriting. Program must be migrated as-is with as little manual change as possible. If the customer wants to make changes later that's up to them.
- vonseel 7y agoBut then again: Is it even a good idea to access the same database from two codebases at all? I think that depends entirely on who you ask. Some orgs may have dedicated DB guys who are designing all the DB schema and stored procedures that must be vetted by the DB guys before the application guys can merge in changes. Others might decide dev teams should be responsible for their own data and store it as they see fit. I think product data should only be updated by one main API and that API exposed internally for other tools to interact with, unless it's something that is special. And in development, there are many special cases.
- bayesian_horse 7y agoMicroservices communicating via an RDBMS sounds like a recipe for chaos.
- oliwarner 7y agoCame here to say this, specifically about Django too. It's pretty bulletproof these days.