Opened 10 years ago
Closed 9 years ago
#22603 closed Cleanup/optimization (fixed)
Reorganize code in django.db.backends
| Reported by: | Aymeric Augustin | Owned by: | Tim Graham |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | 1.8-alpha |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Currently, database backends are split in modules inconsistently. For example:
- in the base implementation, most classes are defined in init.py; in actual backends, most classes are in base.py;
- in the base implementation, BaseDatabaseCreation and BaseDatabaseSchemaEditor have their own modules while other classes are defined in init.py;
- the postgresql backend has an operations.py, other backends don't.
It would be easier to make cross-backend changes if the code was organized consistently.
Considering the size of the classes involved, I think we should put each class it its own module.
Change History (13)
comment:1 by , 10 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 10 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 10 years ago
comment:4 by , 10 years ago
That sounds sensible. I'll put it on hold until closer to the release date. Is the timeline for 1.8 online anywhere? A quick search didn't reveal it.
comment:5 by , 10 years ago
No, we're at least a month behind on the 1.7 release, so that needs to be finished first.
comment:6 by , 10 years ago
| Keywords: | 1.8-alpha added |
|---|
I'm tagging this ticket 1.8-alpha so we can try to make this change close to that date (currently scheduled for January 12) before we fork stable/1.8.x.
comment:7 by , 9 years ago
gchp, are you planning to work on this? I can review your patch or take a look at this before 1.8 alpha.
comment:8 by , 9 years ago
Hey berkerpeksag,
I'm not sure if I'll get time, I don't want to say I will in case I don't. Feel free to assign it to yourself if you like!
Cheers
comment:9 by , 9 years ago
There are still a couple large patches that touch these classes that may make it into 1.8 (in particular, PR 3669), so let's hold off a bit longer on this -- I'm thinking after the "feature freeze" on Monday, but before we cut the branch and issue an alpha release.
comment:10 by , 9 years ago
| Owner: | changed from to |
|---|
comment:12 by , 9 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Considering this is essentially code moving and the test suite is happy, I'd consider this RFC.
comment:13 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
We should do this late in the 1.8 release cycle when there is less of a chance we'll need to backport bug fixes to 1.7.x as reorganizing a lot of code like this will make backporting more painful.