2010-1-30: Accessor clash fix + app restructured (and more changes since Jan. 26)

[Bert Constantin]

2010-1-30

Fixed ContentType related field accessor clash (an error emitted
by model validation) by adding related_name to the ContentType
ForeignKey. This happened if your polymorphc model used a ContentType
ForeignKey. Thanks to Andrew Ingram.

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-28

Added the polymorphic_dumpdata management command (github issue 4),
for creating fixtures, this should be used instead of
the normal Django dumpdata command.
Thanks to Charles Leifer.

Important: Using ContentType together with dumpdata generally
needs Django 1.2 (important as any polymorphic model uses
ContentType).

Kind Regards,
Bert Constantin

[Andrew Ingram]

This seems to solve the problem I was having.

I noticed you left a comment about needing more than the class. It
looks like Django lets you specify '%(app_label)s' as well as '%(class)
s'.

[Bert Constantin]

You're right, my wish for '%(app_label)s' had already been fulfilled
(it seems I only looked into Django 1.1). Thanks that you looked again
into this.

The remaining potential accessor clashes with ContentType are now
resolved (I will update the repository during the next days).

Bert