5 ms·

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 activere

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.

akx 8y ago
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 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.
- zimablue 8y ago
  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.
  - c0un7d0wn 8y ago
    We went the other way around and came up with https://github.com/shosca/django-rest-witchcraft https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery https://github.com/shosca/django-sorcery to integrate sqlalchemy with django as the project was already using sqlalchemy.
meric 8y ago
You might have seen aldjemy already but I thought I might mention it https://github.com/Deepwalker/aldjemy 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/ https://channels.readthedocs.io/en/latest/
- zimablue 8y ago
  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.
kennydude 8y ago
> 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.
OmarGonzalez 8y ago
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
djsumdog 8y ago
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.
- blattimwind 8y ago
  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.
  - Serow225 8y ago
    What are some good examples of the latter type of ORM? Thanks
    - blattimwind 8y ago
      sqlalchemy
blattimwind 8y ago
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.. 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.
andybak 8y ago
> 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.

akx 8y ago

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 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.

zimablue 8y ago
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.
- c0un7d0wn 8y ago
  We went the other way around and came up with https://github.com/shosca/django-rest-witchcraft https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery https://github.com/shosca/django-sorcery to integrate sqlalchemy with django as the project was already using sqlalchemy.

meric 8y ago

You might have seen aldjemy already but I thought I might mention it https://github.com/Deepwalker/aldjemy 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/ https://channels.readthedocs.io/en/latest/

zimablue 8y ago
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.

kennydude 8y ago

> 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.

OmarGonzalez 8y ago

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

djsumdog 8y ago

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.

blattimwind 8y ago
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.
- Serow225 8y ago
  What are some good examples of the latter type of ORM? Thanks
  - blattimwind 8y ago
    sqlalchemy

blattimwind 8y ago

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.. 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.

andybak 8y ago

> 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.