4 ms·
This thread is littered with people singing praise of Django's ORM. He is not the only one. I'm a huge proponent of it as well. > Could you share some resource
by Fradow 7y ago
This thread is littered with people singing praise of Django's ORM. He is not the only one. I'm a huge proponent of it as well.
> Could you share some resources of using it properly for advanced use cases? Good cookbooks etc.
The official documentation covers advanced use cases. Stackoverflow will help you shape up more complicated queries.
> 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.
That's a drawback of most dynamic languages, not a flaw of Django's ORM.
> 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.
Maybe that's the threshold Django ORM devs thought sensible to stop supporting? At some point, mixing hand-coded-SQL and ORM code introduce a whole set of hard questions and decisions. Very few people expect ORM code to properly play with hand-coded-SQL. If you need to switch back to SQL, you are generally on your own.
> 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 :|...
It's simple to use, yet have complex internals. That's about what I would expect from a tool abstracting something complicated.
- yorwba 7y ago>> 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. > That's a drawback of most dynamic languages, not a flaw of Django's ORM. In Python, mistyping a name usually results in an exception at runtime. If Django doesn't check models for correctness, it can't be explained by being written in a dynamic language.
- _visgean 7y agoi mean if you try to access undefined attribute in model it will throw an exception
- Fradow 7y agoIn Python, mistyping a property of an object doesn't result in an exception. JS have the same behavior. If you mistype a property on a nullabe or already filled property of a model instance, Django will happily save the model with the mistyped property (which will be ignored because it's not part of the model) without actually modifying anything in database. Calling that behavior a flaw of Django's ORM is disingenuous.
- shakna 7y ago> In Python, mistyping a property of an object doesn't result in an exception. Sure it does. It doesn't on assignment, as you can modify the object however you like, but it does have AttributeError for accessing a property that doesn't exist.
- Brometheus 7y agoActually it does on asignments to `__slots__`-based classes.
- djd20 7y agoWhich you can only use compile time - not dynamically. That said I recall the sqlalchemy orm reject fields that it did not recognize. A decent IDE (pycharm) will hilight these for you on the Django orm. Having now used both the Django orm and SQLAlchemy extensively I prefer SQLAlchemy a lot. The Django ORM is usable, but many of its behaviours are odd and I agree that writing more complex queries gets ugly fast, unlike with SQLA where you can write some really hairy sql in a composable manner that makes it just so much more legible.
- yorwba 7y agoThere is no such distinction between compile time and run time in Python; everything can be done dynamically. Want to use a class with slots computed at runtime? No problem: >>> def with_slots(**kwargs): ... class SlottedClass(object): ... __slots__ = kwargs.keys() ... def __init__(self, **kwargs): ... for k, v in kwargs.items(): ... setattr(self, k, v) ... return SlottedClass(**kwargs) ... >>> with_slots(foo=1, bar='qux').zork = 4 Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'SlottedClass' object has no attribute 'zork' Of course there are many improvements that could be made to this approach (e.g. not creating a new class for each instance, or setting the __name__ to something meaningful) but I hope it shows that dynamic typing and robust error checking aren't contradictory.
- bayesian_horse 7y agoIf you misspell the property when setting the value, there is no error. Again, this can be caught by eye, by testing and probably soon by static type checkers.