84 lines
3.1 KiB
ReStructuredText
84 lines
3.1 KiB
ReStructuredText
**2010-1-26**
|
|
IMPORTANT - database schema change (more info in change log).
|
|
I hope I got this change in early enough before anyone started to use
|
|
polymorphic.py in earnest. Sorry for any inconvenience.
|
|
This should be the final DB schema now.
|
|
|
|
|
|
Usage, Examples, Installation & Documentation, Links
|
|
----------------------------------------------------
|
|
|
|
* Please see the `Documentation and Examples`_ (or the short `Overview`_)
|
|
* If you have comments or suggestions: `Discussion, Comments, Suggestions`_
|
|
* The code can be found on GitHub_ and Bitbucket_, or downloaded as TGZ_ or ZIP_
|
|
|
|
.. _Documentation and Examples: http://bserve.webhop.org/wiki/django_polymorphic/doc
|
|
.. _Discussion, Questions, Suggestions: http://django-polymorphic.blogspot.com/2010/01/messages.html
|
|
.. _GitHub: http://github.com/bconstantin/django_polymorphic
|
|
.. _Bitbucket: http://bitbucket.org/bconstantin/django_polymorphic
|
|
.. _TGZ: http://github.com/bconstantin/django_polymorphic/tarball/master
|
|
.. _ZIP: http://github.com/bconstantin/django_polymorphic/zipball/master
|
|
.. _Overview: http://bserve.webhop.org/wiki/django_polymorphic
|
|
|
|
|
|
What is django_polymorphic good for?
|
|
------------------------------------
|
|
|
|
It causes objects being retrieved from the database to always be returned back
|
|
with the same type/class and fields they were created and saved with.
|
|
|
|
Example:
|
|
If ``ArtProject`` and ``ResearchProject`` inherit from the model ``Project``,
|
|
and we have saved one of each into the database::
|
|
|
|
>>> Project.objects.all()
|
|
.
|
|
[ <Project: id 1, topic: "John's Gathering">,
|
|
<ArtProject: id 2, topic: "Sculpting with Tim", artist: "T. Turner">,
|
|
<ResearchProject: id 3, topic: "Swallow Aerodynamics", supervisor: "Dr. Winter"> ]
|
|
|
|
It doesn't matter how these objects are retrieved: be it through the
|
|
model's own managers/querysets, ForeignKeys, ManyToManyFields
|
|
or OneToOneFields.
|
|
|
|
``django_polymorphic`` does this only for models that explicitly request this behaviour.
|
|
|
|
The resulting querysets are polymorphic, i.e they may deliver
|
|
objects of several different types in a single query result.
|
|
|
|
|
|
Status
|
|
------
|
|
|
|
It's important to consider that this code is still very new and
|
|
experimental. Please see the docs for current restrictions, caveats,
|
|
and performance implications.
|
|
|
|
Right now it's suitable only for the more enterprising early adopters.
|
|
|
|
It does seem to work well for a number of people (including me), but
|
|
it's still very early and API changes, code reorganisations or further
|
|
schema changes are still a possibility.
|
|
|
|
|
|
News
|
|
----
|
|
|
|
**2010-1-29:**
|
|
|
|
Restructured django_polymorphic into a regular Django add-on
|
|
application. This is needed for the management commands, and
|
|
also seems to be a generally good idea for future enhancements
|
|
as well (and it makes sure the tests are always included).
|
|
|
|
The ``poly`` app - until now being used for test purposes only
|
|
- has been renamed to ``polymorphic``. See DOCS.rst
|
|
("installation/testing") for more info.
|
|
|
|
**2010-1-26:**
|
|
|
|
IMPORTANT - database schema change (more info in change log).
|
|
I hope I got this change in early enough before anyone started to use
|
|
polymorphic.py in earnest. Sorry for any inconvenience.
|
|
This should be the final DB schema now.
|