4 ms·
When I look at django apps they are often similarly hideous to me. (edit: such as - when hundreds of objects are pulled into memory, then filtered further, or
by zzzeek 14y ago
When I look at django apps they are often similarly hideous to me. (edit: such as - when hundreds of objects are pulled into memory, then filtered further, or processed one at a time, when the entire thing could be done in one query. They'll do this not only because the Django ORM isn't capable enough to do the work out on the query side, but also because the programmer isn't SQL-aware enough to know that's even how it should be done. Django's lack of capability is matched by the developers lack of awareness, and the conclusion for such a developer is "django works great!" This is why SQLAlchemy users get annoyed by Django and Django users get annoyed by SQLAlchemy. There are two totally different ways of looking at problems going on).
This whole thing is about where you're coming from and what software development traditions you subscribe to. We know full well django isn't going anywhere and you can rebut all you want, the alternatives aren't going away either.
- anthonyb 14y agoWell, when I see code like that, I see lots of moving parts, all with their own weird API, interacting in odd ways. You just have to know that thing X takes a string, an object and a callback function, and there are twenty thing Xs, not five. Complexity breeds bugs like rabbits; if you can't look at something and understand what's going on (potentially drilling down into an abstraction or two), then it's going to be a maintenance nightmare. If you can come up with something that's easy to use and powerful, like the declarative_base stuff in SQLAlchemy over the top of the Mapper/Relationship, then I'm all ears - but if complexity is the price that I have to pay for that then it's not an easy tradeoff to make, and in a lot of cases you're better off with the easier, worser solution. A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly? ie. so that all of the fancy Django manage commands work. I'm assuming a fair bit, but it might be a good way to get some sort of help as far as SQLAlchemy goes. Or you might be happy to continue forging ahead solo, I don't know. Just a thought ;)
- zzzeek 14y ago> A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly? There is a version of this I have in mind that would take at least 6-8 weeks of pretty solid developer time. A new layer would be built on top of SQLAlchemy ORM that would look just like Django mappings/QuerySet. The mappings wouldn't be too difficult, QuerySet maybe a little more. The advantage to that approach would be that existing Django mappings and QuerySet code could be reused in the context of a SQLAlchemy session conversation, that is, the unit of work/identity map paradigms would be brought in. A lot of the "bolted-on/doesnt-really-work" code I see to approximate these features in a tool like JohnnyCache wouldn't be needed anymore. I'm not sure that this really encompasses "manage" though, I'd have to increase my familiarity with that tool to know everything it does.