Hacker News Reader

Comment by zimablue | Hacker News Reader

As a counter point, I tried to use Django for a data-visualisation project and ran into some problems. Everything is built on models, which are kind of activerecord pattern. Django has an inbuilt (and inferior) version of sqlalchemy, so that when you want to push sql past a certain point (define queries more complex than the api) you're pretty much stuck. Now you have codebase with two different database libraries in it. You're probably using an spa so all the view stuff isn't helping, and Django kind of infects your code because it won't run without an initializarltion step so if you have a module importing something that imports Django, any time you use that it needs to initialize Django itself. I don't think that these are mistakes, just choices that they made that make it very good for websites up to a certain (sql/data) complexity and very annoying afterwards.

View on HN

Pyramid is often forgotten. It's genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really help. Pyramid on the other hand has a simple and extensible interface to support multiple templates and other renderers ( https://docs.pylonsproject.org/projects/pyramid/en/latest/na.... ). This is a common theme with Pyramid. Another is avoiding global state; they're quite successful at that (vs. "I declare my entire app/blueprint within a function"-Flask and "I don't know how this works, it's just like magic. I go to my model class and, BAM, suddenly I'm connected to some database"-Django). Django ORM is awkward and not that good, but awkward to replace.

The Django ORM has raw SQL escape hatches (either fully raw SQL database connections or model instance selections with SQL), and if you do need the SQLAlchemy query builder, slap in something like https://github.com/Deepwalker/aldjemy .

As for the initialization stuff -- yes, that's true; whenever Django models are being imported, you do need to have had `django.setup()` called.

yea good point, I should have mentioned the raw SQL escape hatch, that also isn't an ideal solution. I went for aldjemy/instead them and in retrospect starting with something sqlalchemy native would have been cleaner.

We went the other way around and came up with https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery to integrate sqlalchemy with django as the project was already using sqlalchemy.

> Django kind of infects your code because it won't run without an initializarltion step

Most people using Django have built their apps as Django apps so this is a "non issue".

The worst way to use Django is to try and fight against the way it was built. For your case specifically, it's probably not a good option.

You might have seen aldjemy already but I thought I might mention it https://github.com/Deepwalker/aldjemy - let's us use SQLAlchemy queries in our django code without requiring redefining the models in an SQLAlchemy manner. It's easy to put a wrapper around it to convert SQLAlchemy results back into Django model instances.

I'm exploring using Django Channels to send data to visualisation SPA's in realtime. https://channels.readthedocs.io/en/latest/

Yep I'm using Aldjemy as a bridge for now and it works great. I still really don't like having two completely different db layers in the same codebase. Whilst we're plugging the ecosystem/extensions, I also use Alembic which is amazing.

> Django has an inbuilt (and inferior) version of sqlalchemy

Django has it's own ORM with a different design philosophy that is optimised for a different use-case to sqlalchemy.

Django's ORM is generally cleaner and more readable for the common case and requires less code to set up. It might be slightly less elegant for more complex cases but it's a trade off that's made me pretty happy on balance.

I mean that's a general problem with ALL ORMs. I've been on Django projects where we had to drop down and pass raw SQL statements.

On my current project we don't use an ORM; just SQL statements and we create classes to match the result set and map into them.

Disagree. It's mostly a question of whether the ORM was designed as a "least-common denominator of common operations supported by some RDBMSs" (which is clearly the case for the Django ORM) or as an abstraction of SQL concepts (i.e. a form of relational algebra). The former category generally fares poorly with complex queries or structures; the latter exceeds at them.

What are some good examples of the latter type of ORM? Thanks

sqlalchemy

I don't disagree with your assessments of django limitations. It does however, seems like a poor choice for your specific problem.

This is why the problem inform the solution, pick the framework (or lack of) that suits your problem best

Reply on news.ycombinator.com