[WIP] - Refactor ORM with VirtualField and CompositeField#39
[WIP] - Refactor ORM with VirtualField and CompositeField#39auvipy wants to merge 82 commits intodjango:mainfrom
Conversation
auvipy
changed the title
auvipy
changed the title
auvipy
changed the title
auvipy
left a comment
auvipy
left a comment
There was a problem hiding this comment.
should also figure out which parts of django should also need to be taken care of for the proposed changes
|
|
||
| Background: | ||
| =========== | ||
| Django's ORM is a simple & powerful tool which suits most use-cases. |
There was a problem hiding this comment.
might be adjusted with more streamlined detail of the back ground of the project
|
|
||
| Abstract | ||
| ========== | ||
| This DEP aims to improve different part of django ORM and associated |
There was a problem hiding this comment.
this part could be more organized
|
|
||
|
|
||
| Key steps of to follow to improve ORM Field API internals: | ||
| ============================================================== |
There was a problem hiding this comment.
might add slight more elaboration about each steps
|
|
||
| New split out Field API | ||
| ========================= | ||
| 1. BaseField: |
There was a problem hiding this comment.
could add some detail about how baseField might look like and what role it will play
| Base structure for all Field types in django ORM wheather it is Concrete | ||
| or VirtualField | ||
|
|
||
| 2. ConcreteField: |
There was a problem hiding this comment.
might be a ConcreteField mixing?
| ----------------- | ||
|
|
||
| 5. VirtualField: | ||
| ---------------- |
There was a problem hiding this comment.
add specs based on Old work and new BaseField
|
|
||
| Proposed API and workd flow for clean ups: | ||
| ========================================== | ||
|
|
There was a problem hiding this comment.
some suggestions from available tickets could be sorted out and another approach could be simpler new API for relationFields/ReverseRelation/ForwardRelation/RemoteRelation etc
| ------------------------- | ||
| "A virtual field is a model field which it correlates to one or multiple | ||
| concrete fields, but doesn't add or alter columns in the database." | ||
|
|
There was a problem hiding this comment.
How migrations should be effected with virtualFields inclution in related fields?
| ============================= | ||
| Relationship fields | ||
| ~~~~~~~~~~~~~~~~~~~ | ||
|
|
There was a problem hiding this comment.
this part should be adjusted with rel clean up and newer Field API
|
|
||
| ``contenttypes`` and ``GenericForeignKey`` | ||
| ========================================== | ||
|
|
There was a problem hiding this comment.
This part should conform with FieldAPI, RelationFIeld, ReverseRelation, VirtualFIelds etc
auvipy
changed the title
… reverse relation
|
|
||
| In order to fix these design limitations and inconsistancies, the proposed | ||
| solution is to refactor Fields/RelationFields to new simpler API and | ||
| incorporate virtualField type based refctors of RelationFields. |
There was a problem hiding this comment.
yes you r right. I have to adjust the dep based on master
|
I wonder if it is worth taking into account what something like django-polymorphic needs? (I'm not myself qualified to say what that might be). |
|
i think django-polymorphic should be improved by the changes if done correctly |
|
@auvipy is this something you're still interested in working on? |
4 participants
This is a very early WIP draft. I am still working on figuring out some issues and proper approaches.
I will share it on mailing list soon after I think it's ready for initial review. Any improvement suggestions are highly welcome.