2010-11-17: V1.0 Beta 2

[Bert Constantin]

V1.0 Beta 2 is online on github and bitbucket.

Beta 2 accumulated more changes than intended, and also has been
delayed by some DBMS benchmark testing I wanted to do on model
inheritance. These benchmarks indicate that current DBM systems can be
rather slow when processing the sql queries issued by Django for
models using concrete inheritance.
Concrete benchmarks are forthcoming.

The API should be stable now with Beta 2, so it's just about potential
bugfixes from now on regarding V1.0.

Beta 2 is still intended for testing and development environments and
not
for production. There will be a release candidate for V1.0 in the very
near future.

Please see the changelog (it's also copied below):
http://bserve.webhop.org/django_polymorphic/CHANGES.html

The documentation:
http://bserve.webhop.org/django_polymorphic/README.html
http://bserve.webhop.org/django_polymorphic/DOCS.html

The code:
GitHub: http://github.com/bconstantin/django_polymorphic
Bitbucket: http://bitbucket.org/bconstantin/django_polymorphic
Tar: http://github.com/bconstantin/django_polymorphic/tarball/master

Kind Regards,
Bert Constantin

========================================================

New Features and API changes in Beta 2 since Beta 1
---------------------------------------------------

* API CHANGE: ``.extra()`` has been re-implemented. Now it's
polymorphic by default and works (nearly) without restrictions
(please
see docs). This is a (very) incompatible API change regarding
previous
versions of django_polymorphic. Support for the ``polymorphic``
keyword parameter has been removed.
You can get back the non-polymorphic behaviour by using
``ModelA.objects.non_polymorphic().extra(...)``.

* API CHANGE: ``ShowFieldContent`` and ``ShowFieldTypeAndContent``
now use a slightly different output format. If this causes too
much
trouble for your test cases, you can get the old behaviour back
(mostly) by adding ``polymorphic_showfield_old_format = True`` to
your model definitions. ``ShowField...`` now also produces more
informative output for custom primary keys.

* ``.non_polymorphic()`` queryset member function added. This is
preferable to using ``.base_objects...``, as it just makes the
resulting queryset non-polymorphic and does not change anything
else in the behaviour of the manager used (while ``.base_objects``
is just a different manager).

* ``.get_real_instances()``: implementation modified to allow the
following more simple and intuitive use::

>>> qs = ModelA.objects.all().non_polymorphic()
>>> qs.get_real_instances()

which is equivalent to::

>>> ModelA.objects.all()

* added member function:
``normal_q_object =
ModelA.translate_polymorphic_Q_object(enhanced_q_object)``

* misc changes/improvements

Bugfixes
------------------------

* Custom fields could cause problems when used as the primary key.
In derived models, Django's automatic ".pk" field does not always
work correctly for such custom fields: "some_object.pk" and
"some_object.id" return different results (which they shouldn't,
as pk
should always be just an alias for the primary key field).
It's unclear yet if the problem lies in Django or the affected
custom
fields. Regardless, the problem resulting from this has been fixed
with a small workaround. "python manage.py test polymorphic"
also tests and reports on this problem now.
Thanks to Mathieu Steele for reporting and the test case.