#16559 closed Uncategorized (invalid)
Switch to entity-manager type system.
| Reported by: | anonymous | Owned by: | nobody |
|---|---|---|---|
| Component: | Uncategorized | Version: | 1.3-rc |
| Severity: | Normal | Keywords: | |
| Cc: | xaav@… | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I realize that I am submitting this ticket as anonymous, which will give it reduced credibility, but at least consider the logic posted here, and before you close this ticket, state your reason and give me time to reply. All I am trying to do here is implement a change, that in my opinion, will make django closer to your design philosophies.
This suggestion is mostly based on the "SQL efficiency" philosophy.
Instead of using Model.save(), you should change the framework to implement a entity-manager approach, like doctrine does. This would allow a one-time SQL calculation, providing maximum efficiency. Instead of running an SQL query for each changed model, only one query would be needed for all of them.
I realize this would be a BIG change to implement; I would recommend it for a major release version. However, this would make django more perfect in regard to the design philosophies, also writing less Model.save() calls and only one em.flush() call. I hope you seriously consider this change instead of just blowing it off; I think it would be very beneficial to django.
I'm closing this ticket for a number of reasons.
Firstly, Trac is completely the wrong forum in which to have this discussion. You're proposing a *major* change to Django's ORM. Even if we accept as given the proposition that this is a great idea, it's something that would need to be discussed extensively in the Django community before we decided to go forward. As is documented in our contributing guide, Trac isn't the place to have that discussion.
Secondly, I'm particularly wary of any suggestion that takes the form of "Django would be awesome if only it were completely different", *especially* when it comes from an anonymous contributor. If you take off your mask and reveal yourself to be someone with great experience in the Django community or in ORM circles, then your claims would carry a bit more weight.
Thirdly, I don't accept your proposition that this would be an improvement. From the link you provided, it isn't clear to me why the abstraction would be a clear and obvious improvement to the ORM model. At best, it looks like it might be a way to implement #4102 -- and we can do that without making a massive change to the ORM.
Fourth, if Django were to make a massive ORM change, I'd lay money that the most likely proposition to be accepted would be "make Django's ORM a wrapper around SQLAlchemy", or something of that ilk.
Lastly, blue sky propositions like this don't go anywhere unless there is someone that's going to implement them. If you had a working prototype attached as a patch (or as a branch on github/bitbucket), then it might be worth keeping this ticket open for reference purposes. However, at the moment, it's the seed of a vague idea and nothing more. We try to keep Trac a list of clearly actionable items, not vague open ended dreams and aspirations.
If you think this idea is worth pursuing, then follow the instructions in the contributing guide, and start a discussion on django-developers.