Maybe this is just a symptom of working in a field with plenty of work opportunities, or the fact that I am not American, but the idea of a company demanding that I relocate in order to be closer to an office is comical at best.
> Djangos ORM isn't highly opinionated. That's just wrong.
It's a fully featured ORM... Including migrations, query API (which is HIGHLY opinionated, it looks nothing like SQL), supports async (via asgiref!), custom model definition... It's almost the definition of opinionated. Not that you can build a fully featured ORM without being opinionated. That's not a dig at Django btw.
> Also, worrying about being "locked into" something that you depend on is madness. Where does it end? Do you worry about being "locked into" Python? Of course not.
Ermm, my premise is that you DON'T have to depend on it. It's not that crazy to not want lock in when it comes to the software that handles my database. Other programming language communities seem to handle that just fine.
The rest is a bit too ad hominem for my liking, so I'll pass.
I don't think it is farfetched to say that, for the good and bad, modern software development is moving away from a single project having to handle "1200 tables". As we see the growth of "services" (gasp, microservices!), the scope for codebases is reduced, hence why the pattern in my post (OP here) is so common to see in Go. Are Go developers masochists? No... But when you're working on (micro)services and your immediate work only touches 5 tables and the relationship between them, it's really not inconceivable to just reach for a database adapter and simple abstractions.
> I swear the majority of these opinion posts against ORMs are from people who must have worked in a badly implemented project that left them with a bad experience and they blamed the pattern rather than the technology.
Fair. But you then proceed to detail a personal experience on the other side of the spectrum: Badly written code, without an ORM, and how it was fixed by introducing an ORM.
I think we can all agree that you can write bad code, with or without an ORM :). Not that this is entirely relevant to my post, I am simply advocating for writing more SQL, not how to write a good object mapper. That's a different beast, and I purposely kept that simple just to illustrate that it is possible to get started without too much pain.
First of all, thank you for SQLAlchemy! If I ever had to make a final choice in how I would interact with a database for a very large project that involves a considerable dev team, I would always bet on SQLAlchemy. Not that I would necessarily like all aspects of it, but when it comes to Python and SQL - “Nobody ever got fired for picking SQLAlchemy.”.
With that out of the way, despite ORMs doing much more than "just writing SQL", it is exactly on that point that I flinch: Most devs should be exposed to SQL. And if your project allows you to build around simple enough abstractions so that you aren't reinventing the wheel, you should definitely be writing SQL. Especially if you don't know SQL yet - which is the growing case of new devs coming into the job market.
You can achieve a lot with SQlAlchemy Core, a tool that I absolutely recommend, but my post is just a simple alternative to get developers to think about their approach. If that results in some devs reconsidering using "full fat" SQLAlchemy and to try SQLAlchemy Core, that's a win for me!
Your gist tries to highlight the difficulty of doing certain things without an ORM. Migrations (as just 1 example) doesn't need to be hard, simple tools like flyway, or migrate (https://github.com/golang-migrate/migrate) achieve a similar result (while also keeping you on the path of writing SQL!). Deep and complex relationships between objects also don't need to be hard - typically people approach this subject with a requirement to be very flexible in the way they want to build queries and objects, but that to me in a sign that maybe they should reconsider their business logic AND reconsider that, just maybe, their project doesn't require all that flexibility, it is fairly straightforward to extend objects and introduce some more complex representations as and when it is needed - will all of this make me write code faster? Absolutely not. That is why you have spent so much time perfecting SQLAlchemy, but then again, I am not advocating for devs to go and replace their usage of ORMs, just presenting an alternative that may or may not fit their needs for a new project + give devs the chance to learn something that the ORM might have taken away.
> This is just reimplementing Djangos ORM, bud badly.
I guess this is a good thing, as "reimplementing" Django's ORM is the opposite of what I wanted to do here :)
> ORM queries compose. That's why [Python] programmers prefers them. You can create a QuerySet in Django, and then later add a filter, and then later another filter, and then later take a slice (pagination). This is hugely important for maintainable and composable code.
I don't really disagree, but there are many ways to skin a cat. You can absolutely write maintainable code taking this approach. In fact, I can build highly testable, unit, functional, code following a abstraction very similar to this. The idea that "maintainable and composable code" can only be achieved by having a very opinionated approach to interacting with a database, is flimsy. I offer a contrary point of view: With the Django ORM, you are completely locked in to Django. You build around the framework, the framework never bends to your will. My approach is flexible enough to be used in a Django project, a flask project, a non web dev project, any scenario really. I want complete isolation in my business logic, which is what I try to convey just before my conclusion.
This is also why I really like Peewee in Python. If I am not going to write SQL, at least give me an API that looks and feels like it. When I look at Peewee code, I can often see the end result query.
There are a multitude of extra things to consider, but none of those things are, in my opinion, imperative to having success with SQL in Python. Will it be hard to achieve the same level of convenience that modern ORMs provide? Absolutely. But there is always a cost.
I firmly believe that for most projects (especially in the age of "services"), an approach like this is very much good enough. Also, a great way to onboard new developers and present both SQL and simple abstractions that can be applied to many other areas of building software.
There isn't that much to elaborate on. Commercial heat pumps just aren't good for the average UK house. They would be "alright" if the costs weren't prohibitive.
I don't know the specifics of your parents. A "wooden house" with a heat pump acting as the primary heating system in a country like Norway sounds fairly bad on the surface. But I don't know the insulation specifics, nor do I know what other heating element might come at play when the heating pump fails to keep up with the heat loss. Also, what heating pump are we talking about?
Heat pumps take much longer to heat the system, to get it to the desired temperature. Combine that with a property that is not insulated to very high standard, and you get a heating system that is incapable of keeping you warm.
Of course, you could throw more money at it. But it won't be cheap, and you won't see a return on your investment any time soon.
The costs are totally prohibitive, though. We're talking tens of thousands of pounds, whatever direction you decide to take.
You could spend 10s of thousands of pounds in a "properly sized" heat pump system. Or you could spend 10s of thousands of pounds in insulating your home + a more moderate heat pump.
> The load also depends on unique characteristics of the home like the amount of insulation or the type of windows and doors. A home built in 1850 with no insulation requires more energy than a brand new home. The load is just a technical way to describe and measure all of this.
No kidding. The site is all about switching from carbon, which I am all for, as would anyone that cares even slightly about the planet.
BUT. If you do live in a 1850s house with no insulation, getting a heat pump is a colossal waste of money that will not do the job. No matter how many fancy biased graphs and numbers someone comes up with.
Any responsible heat pump installer will firstly look at your home to determine if a heat pump is remotely feasible. Unfortunately, in the UK, only very recent new builds can comfortably accommodate a heat pump. That or older properties that have had CONSIDERABLE insulation work done to them (and I am talking the expensive kind like internal/external wall work, not just the easy jobs like loft insulation).
Be very careful with heat pump cowboys, if you are getting quotes that don't include a site inspection, run.
Years ago I visited my home country with my partner. She used to prefer going to dentist there, old habits I guess. On this particular trip I agreed to a check up as well - It had been a while since I had my teeth checked, why not?
Really fancy dentists. Big offices, flashy machines, everything looked pristine. X-rays are taken, teeth are checked. Result: You need root canal! You should have it done soon, it's going to get much worse and hurt a lot more! We can do book you in ASAP.
Hollllld on. I was on holiday, I'm not about to have a root canal procedure done and ruin my time off. I'll take the xrays and check back with a dentist back home.
I pay dearly for the check and xrays and proceed to not enjoy my time off as much as I could have - I was worried.
Fly back home, book a session with my usual dentist. "I can't see anything wrong with this tooth. But let me do an xray as well... Nope. Can't see anything wrong."
It has been around 5 years now. That dentist would have performed root canal on me for no apparent reason...
One really interesting conversation I had with my usual dentist:
Me: So really, nothing wrong? Why would they say otherwise?
Dentist: Nothing wrong. I'm not sure why they told you otherwise.
Me: That's just...
Dentist: Tell you what, they say it's this tooth points, right? Do any other of your teeth look different in the xray? Check the root as well, pay close attention.
Me: I don't see any difference, but I'm not a dentist...
Dentist: Well, I am a dentist, but I also see no difference.
An Anker Power Bank (24,000mAh) has a £40 discount right now on Amazon UK.
This is a really nice piece of tech that has helped me to work outside the house with peace of mind. Can keep my phone charged (which I use for tethering) for over a week, no problem. Drains way quicker when charging my M1, but that one has far less battery issues when compared to my phone.
The discount is real, as well. I know because I bought it recently, but you can also check it against camelcamelcamel or keepa.
See, the thing with DDD is that it is VERY complex. I mean, "the" book on it (Evans) is beefy. Putting all those ideals in practice is hard, especially when so many of the ideas are not necessarily to do with the act of software development - No, they are social concepts, the way a team should approach the business and people outside of the tech teams.
That's why every single implementation of DDD is different. Every company that "implements" DDD does it differently. I've seen this a few times now.
Yep. This is exactly how I feel. Django is great to get projects going, but eventually you just end up fighting it a lot.
I even recommend people not to install too many flask extensions, just use Django if that is how you like your development. Flask is much better when you just build for it - It takes longer to deliver, but you'll be enjoying that project for years.
This is probably quite unpopular, seeing as the FastAPI docs have been so praised in the past... but I really dislike how FastAPI is documented, which has really put me off of the project.
The FastAPI docs read like a full project, a very dense project. Sometimes you just want to learn about a specific feature, but you walk into a page that assumes you have the context of the previous chapters, that puts me off a lot.
I also dislike how some of the documentation is absolutely enormous (the SQL chapters is one example), but I suspect this might have to do with the not-so-simple approach FastAPI takes, as opposed to Flask, which is indeed very simple.
I really can't join the crowd here. I don't think FastAPI is a replacement for Flask, even when async is taken out of the equation. Flask has some weird quirks to it (like "g"), but it really is a beautiful and simple API for the web.