Code

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

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

Attachments (0)

Change History (2)

comment:1 Changed 3 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:2 Changed 3 years ago by jacob

Milestone 2.0 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.