It would be helpful for new contributors as well as for other core devs
not involved in certain parts of Django, to have documentation that
outlines how these components work.
I.e. in migrations: you have a `ModelState` and to detect changes the
autodetector takes all migrations and build the final model representation
and then compares this `ProjectState` to the `ProjectState` constructed
from all currently available models.
Tim proposed to add that documentation to `docs/internals/`. I'd put it
into `docs/internals/api/`
--
Ticket URL: <https://code.djangoproject.com/ticket/24989>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by timgraham):
I think the idea is accepted, but a ticket is needed for each thing you
want to document, not all of them in one ticket. Do you want to retitle
this one to cover migrations?
--
Ticket URL: <https://code.djangoproject.com/ticket/24989#comment:1>
* owner: nobody => MarkusH
* status: new => assigned
* stage: Unreviewed => Accepted
Old description:
> I first had the idea a Django: Under the Hood 2014, but abandoned it. A
> couple of days ago the idea came up in IRC again:
>
> It would be helpful for new contributors as well as for other core devs
> not involved in certain parts of Django, to have documentation that
> outlines how these components work.
>
> I.e. in migrations: you have a `ModelState` and to detect changes the
> autodetector takes all migrations and build the final model
> representation and then compares this `ProjectState` to the
> `ProjectState` constructed from all currently available models.
>
> Tim proposed to add that documentation to `docs/internals/`. I'd put it
> into `docs/internals/api/`
New description:
It would be helpful for new contributors as well as for other core devs
not involved in certain parts of Django, to have documentation that
outlines how these components work. Tim proposed to add that documentation
to `docs/internals/`. I'd put it into `docs/internals/api/`
E.g. in migrations: you have a `ModelState` and to detect changes the
autodetector takes all migrations and build the final model representation
and then compares this `ProjectState` to the `ProjectState` constructed
from all currently available models.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24989#comment:2>
Comment (by akki):
Commenting to subscribe to this ticket.
(Cannot add to cc as being detected as spam)
--
Ticket URL: <https://code.djangoproject.com/ticket/24989#comment:3>
* owner: Markus Holtermann => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/24989#comment:4>
Comment (by HAMA Barhamou):
I think that this tiket should cover a broader need.
[https://forum.djangoproject.com/t/internal-organization-of-the-django-
project/18490]
--
Ticket URL: <https://code.djangoproject.com/ticket/24989#comment:5>
Comment (by Natalia Bidart):
Replying to [comment:5 HAMA Barhamou]:
> I think that this tiket should cover a broader need.
[https://forum.djangoproject.com/t/internal-organization-of-the-django-
project/18490]
Hey HAMA Barhamou, thank you for your interest in making Django better,
but please note that as mentioned in the first comment from Tim, this
ticket is intentionally scoped to only documenting the database migrations
machinery.
--
Ticket URL: <https://code.djangoproject.com/ticket/24989#comment:6>