Package: django-dfk
django-dfk==========django-dfk implements deferred foreign keys for Django. Deferred foreign keys are conceptuallysimilar to generic foreign keys, except that they are resolved to a real foreign key at runtime,and cause proper foreign keys to be created in the database.This package allows you to do two things::* Declare that a model's foreign key field is 'deferrable', and should be repointed later* Repoint an existing model's foreign key fields, even if that model is not django-dfk aware.You should perform the latter with caution - consider it a similar process to monkey-patching!This package is alpha software, and is not feature-complete. See the TODO section for what'son the list.django-dfk is compatible with Python 2.6, 2.7, 3.2 and 3.3.django-dfk is compatible with django versions 1.3 - 1.7Installation============Install ``django-dfk`` using your preferred Python package manager. Use of ``virtualenv`` isalso recommended::pip install django-dfkUsage=====Pointing a single foreign key-----------------------------Let's say you want to reinvent the wheel, and develop a commenting app. Your comment modelmight look like this, in ``mycomments.models``::from dfk import DeferredForeignKeyclass Comment(models.Model):commenter = models.ForeignKey('auth.User')content = DeferredForeignKey()body = models.TextField()Now, you come to integrate this application with your blog system (which, as you're keenon wheel reinvention, you have also written yourself). Here's ``blog/models.py``::from dfk import pointfrom mycomments.models import Commentclass BlogPost(models.Model):title = models.CharField(max_length=100)slug = models.SlugField()body = models.TextField()point(Comment, 'content', BlogPost)The call to ``point`` will replace the ``DeferredForeignKey`` on ``Comment`` with a foreign key to BlogPost.Pointing many foreign keys at once----------------------------------When writing models that use deferred foreign keys, you may need to declare that a numbershould point to the same 'kind' of object. Let's say you had wild scope creep, and yourcommenting app needed the ability to associate images with a blog post. So you edityour comment app's models.py so it looks like this::from dfk import DeferredForeignKeyclass Comment(models.Model):commenter = models.ForeignKey('auth.User')content = DeferredForeignKey(name='Content')body = models.TextField()class Image(models.Model):image = models.ImageField()content = DeferredForeignKey(name='Content')This expresses that both comments and images need to point to the same kind of model. This isaccomplished with the ``point_named`` function::from dfk import point_namedpoint_named('blog', 'Content', BlogPost)Now, all ``DeferredForeignKey`` instances in the ``blog`` app which are called ``Content`` willbe replaced by real foreign keys to ``BlogPost``.Arguments to the generated foreign keys---------------------------------------When declaring a deferred foreign key, you may specify additional keyword arguments. Aside from``name``, this will be passed on verbatim to the final foreign key.It is also possible to pass arbitrary keyword arguments in calls to ``point`` or ``point_named``.These will also be passed to the final foreign key. Where arguments are present in both theDFK definition and in the ``point``/``point_named`` call, arguments from the latter will takeprecedence.Model inheritance-----------------Model inheritance should Just Work. It's possible to have ``DeferredForeignKey``instances on subclasses and base classes. The only thing to be aware of is thatrepointing a dfk on a subclass where the key is actually defined on anon-abstract base class is illegal, and will raise a ``TypeError``.Cleaning object caches----------------------Pointing or repointing foreign keys requires that related object caches arerepopulated as relationships will have changed and things like filtering onrelated objects are likely to fail.By default object caches are cleaned after each ``point`` or ``repoint``.For apps with many ``DeferredForeignKey`` instances involving the same modelit may be more efficient to clean the caches once, after all pointing andrepointing has finished. To enable this pass ``clean_caches=False`` to``point`` or ``repoint`` and then manually call ``clean_object_caches`` asrequired::from dfk import pointfrom dfk import clean_object_cachesfrom mycomments.models import Commentclass BlogPost(models.Model):title = models.CharField(max_length=100)slug = models.SlugField()body = models.TextField()point(Comment, 'content', BlogPost, clean_caches=False)clean_object_caches(Comment, BlogPost)Acknowledgements================Thanks to ISM Fantasy Games Ltd. for sponsoring this package.Package maintained by Dan Fairs, Rob Charlwood and Ian Dash0.0.10=====- Setup Tox environments for Django 1.7- Added MIDDLEWARE_CLASSES definition to test settings to avoid warnings fromDjango 1.7's system check.- Added install_requires limits to setup.py to reflect supported versions ofDjango- Updated docs.0.0.9=====- Setup Tox environments for Django 1.6- Fixed repoint issues under Django 1.6 due to use of new ForeignObject baseclass for related objects.0.0.8=====- Make codebase Python 3 compatible (3.2, 3.3) (robcharlwood@gmail.com).- Make codebase compatible with django 1.5.4 (robcharlwood@gmail.com)- New Python 3 compatible codebase has been tested against django 1.5.4 (robcharlwood@gmail.com)- Carried out full tidy up with PEP8 compliance. (robcharlwood@gmail.com)- Setup and configured ``django-dfk`` for use with ``tox`` testing library (robcharlwood@gmail.com)- Added full documentation on running test suite (robcharlwood@gmail.com)0.0.7=====Make cache cleaning optional, and fix some PEP8 compliance issues. Thanksto Mark Hughes (mark@ismgames.com).0.0.6=====Fix a problem where repointing a deferred foreign key defined on a non-abstractbase class through a subclass would result in a new field being added to thelocal_fields of the subclass, shadowing the one on the base class. It is nowillegal to do this; dfks on base classes should be pointed using the base classitself.0.0.5=====Fix a problem where related object caches on models' _meta Options classeswere not being repopulated on a repoint. This led to problems wherefiltering on a parent model related to a child using a deferred foreign keycould fail if the dfk was (re)pointed after the initial phase of model loadinghad already taken place.0.0.4=====- Include a MANIFEST.in to ensure docs are packaged.0.0.3=====- Fix packaging error0.0.2=====- Fix an issue when repointing foreign keys on model classes with customfields which use the django.db.models.SubfieldBase metaclass- Fix an issue migrating from Django 1.2 to 1.3.0.0.1=====- Initial version