Go to file
Bert Constantin c7ac78e08d Fixed ContentType related field accessor clash (an error emitted by model validation),
by adding related_name to the ContentType ForeignKey. Thanks to  Andrew Ingram.
This happened if a polymorphc model used a ContentType ForeignKey.
Plus minor documentation updates.
2010-01-30 14:15:52 +01:00
pexp Restructured django_polymorphic into a regular add-on application. 2010-01-29 13:41:19 +01:00
polymorphic Fixed ContentType related field accessor clash (an error emitted by model validation), 2010-01-30 14:15:52 +01:00
.gitignore updated docs 2010-01-28 20:39:07 +01:00
AUTHORS updated docs, and moved them to DOCS.rst and README.rst 2010-01-26 14:28:22 +01:00
DOCS.rst Fixed ContentType related field accessor clash (an error emitted by model validation), 2010-01-30 14:15:52 +01:00
LICENSE updated docs, and moved them to DOCS.rst and README.rst 2010-01-26 14:28:22 +01:00
README.rst Fixed ContentType related field accessor clash (an error emitted by model validation), 2010-01-30 14:15:52 +01:00
__init__.py initial commit 2010-01-15 21:13:36 +01:00
dbreset Restructured django_polymorphic into a regular add-on application. 2010-01-29 13:41:19 +01:00
manage.py fix "manage.py dumpdata", by adding polymorphic_dumpdata command (github issue 4) 2010-01-29 00:02:27 +01:00
settings.py Restructured django_polymorphic into a regular add-on application. 2010-01-29 13:41:19 +01:00

README.rst

**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`_)  
* News & comments: `News, Comments, Questions & Discussion`_
* 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 
.. _News, Comments, Questions & Discussion: http://groups.google.de/group/django-polymorphic/topics
.. _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 the models ``ArtProject`` and ``ResearchProject`` inherit from the model ``Project``,
and we have saved one of each of them into the database, then we can do::

	>>> 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 (and implicitely for their submodels).

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.

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.

Right now it's suitable only for the more enterprising early adopters.