Skip to content

Commit

Permalink
docs
Browse files Browse the repository at this point in the history
  • Loading branch information
@bconstantin
bconstantin committed Nov 11, 2010
1 parent 748d10d commit ca329ff
Show file tree
Hide file tree
Showing 8 changed files with 307 additions and 273 deletions.
90 changes: 61 additions & 29 deletions CHANGES.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,17 +7,22 @@
<title></title>
<style type="text/css">

h1, h2, h3, h4 {
h1, h2, h3, h4,
#table-of-contents
{
color: #47c;
}

h1 { padding-top: 15px; }
h2 { padding-top: 10px; }
h3 { padding-top: 7px; }

a:hover { border-bottom: 1px solid #0066cc; }
a {color: #0066cc; text-decoration: none;}

li {
padding-top: 5px;
padding-bottom: 5px;
}

tt {
color: #080;
Expand Down Expand Up @@ -221,32 +226,45 @@ <h1><em>django_polymorphic</em></h1>
<div class="section" id="changelog">
<h1>Changelog</h1>
<div class="section" id="v1-0-beta-2">
<h2>2010-10-25 V1.0 Beta 2</h2>
<div class="section" id="this-is-a-v1-0-beta-testing-release">
<h3>This is a V1.0 Beta/Testing Release</h3>
<p>The release contains a considerable amount of changes in some of the more
critical parts of the software. It's intended for testing and development
environments and not for production environments. For these, it's best to
wait a few weeks for the proper V1.0 release, to allow some time for any
potential problems to show up (if they exist).</p>
<h2>2010-11-11 V1.0 Beta 2</h2>
<div class="section" id="this-is-a-v1-0-testing-release">
<h3>This is a V1.0 Testing Release</h3>
<p>Beta 2 accumulated somewhat more changes than intended, and also
has been delayed by DBMS benchmark testing I wanted to do on model
inheritance. These benchmarks show that there are considerable
problems with concrete model inheritance and contemporary DBM systems.
The results will be forthcoming on the google discussion forum.</p>
<p>Please also see:
<a class="reference external" href="http://www.jacobian.org/writing/concrete-inheritance/">http://www.jacobian.org/writing/concrete-inheritance/</a></p>
<p>The API should be stable now with Beta 2, so it's just about potential
bugfixes from now on regarding V1.0.</p>
<p>Beta 2 is still intended for testing and development environments and not
for production. No complaints have been heard regarding Beta 1 however,
and Beta 1 is used on a few production sites by some enterprising users.</p>
<p>There will be a release candidate for V1.0 in the very near future.</p>
</div>
<div class="section" id="new-features-and-api-changes-since-beta-1">
<h3>New Features and API changes since Beta 1</h3>
<ul class="simple">
<li>API CHANGE: <tt class="docutils literal">.extra()</tt> has been re-implemented. Now it's polymorphic by
default and works (nearly) without restrictions (please see docs). This is an
<div class="section" id="new-features-and-api-changes-in-beta-2-since-beta-1">
<h3>New Features and API changes in Beta 2 since Beta 1</h3>
<ul>
<li><p class="first">API CHANGE: <tt class="docutils literal">.extra()</tt> 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 <tt class="docutils literal">polymorphic</tt> keyword parameter has been removed.
You can get back the non-polymorphic behaviour by using
<tt class="docutils literal"><span class="pre">ModelA.objects.non_polymorphic().extra()</span></tt>.</li>
</ul>
<ul class="simple">
<li><tt class="docutils literal">.non_polymorphic()</tt> queryset member function added. This is preferable to
<tt class="docutils literal"><span class="pre">ModelA.objects.non_polymorphic().extra(...)</span></tt>.</p>
</li>
<li><p class="first">API CHANGE: <tt class="docutils literal">ShowFieldContent</tt> and <tt class="docutils literal">ShowFieldTypeAndContent</tt> 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
<tt class="docutils literal">polymorphic_showfield_old_format = True</tt> to your model definitions.
<tt class="docutils literal"><span class="pre">ShowField...</span></tt> now also produces more informative output for custom
primary keys.</p>
</li>
<li><p class="first"><tt class="docutils literal">.non_polymorphic()</tt> queryset member function added. This is preferable to
using <tt class="docutils literal"><span class="pre">.base_objects...</span></tt>, as it just makes the resulting queryset non-polymorphic
and does not change anything else in the behaviour of the manager used (while
<tt class="docutils literal">.base_objects</tt> is just a different manager).</li>
</ul>
<ul>
<tt class="docutils literal">.base_objects</tt> is just a different manager).</p>
</li>
<li><p class="first"><tt class="docutils literal">.get_real_instances()</tt>: implementation modified to allow the following
more simple and intuitive use:</p>
<pre class="literal-block">
Expand All @@ -258,16 +276,29 @@ <h3>New Features and API changes since Beta 1</h3>
&gt;&gt;&gt; ModelA.objects.all()
</pre>
</li>
<li><p class="first">misc changes/improvements</p>
</li>
</ul>
</div>
<div class="section" id="bugfixes">
<h3>Bugfixes</h3>
<ul class="simple">
<li>misc changes/improvements</li>
<li>Custom fields could cause problems when used as the primary key.
In derived models, Django's automatic &quot;.pk&quot; field does not always work
correctly for such custom fields: &quot;some_object.pk&quot; and &quot;some_object.id&quot;
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.
&quot;python manage.py test polymorphic&quot; also tests and reports on this problem now.
Thanks to Mathieu Steele for reporting and the test case.</li>
</ul>
</div>
</div>
<hr class="docutils" />
<div class="section" id="v1-0-beta-1">
<h2>2010-10-18 V1.0 Beta 1</h2>
<div class="section" id="id1">
<div class="section" id="this-is-a-v1-0-beta-testing-release">
<h3>This is a V1.0 Beta/Testing Release</h3>
<p>This release is mostly a cleanup and maintenance release that also
improves a number of minor things and fixes one (non-critical) bug.</p>
Expand Down Expand Up @@ -315,10 +346,10 @@ <h3>New Features</h3>
</li>
</ul>
</div>
<div class="section" id="bugfixes">
<div class="section" id="id1">
<h3>Bugfixes</h3>
<ul class="simple">
<li>removed requirement for primary key to be an IntegerField.
<li>Removed requirement for primary key to be an IntegerField.
Thanks to Mathieu Steele and Malthe Borch.</li>
</ul>
</div>
Expand All @@ -329,9 +360,10 @@ <h3>API Changes</h3>
and has been disabled, as the regular Django dumpdata command now automatically
works correctly with polymorphic models (for all supported versions of Django).</p>
<p><strong>Output of Queryset or Object Printing</strong></p>
<p>In order to improve compatibility with vanilla Django, printing quersets does not use
django_polymorphic's pretty printing by default anymore.
To get the old behaviour when printing querysets, you need to replace your model definition:</p>
<p>In order to improve compatibility with vanilla Django, printing quersets
(__repr__ and __unicode__) does not use django_polymorphic's pretty printing
by default anymore. To get the old behaviour when printing querysets,
you need to replace your model definition:</p>
<pre class="doctest-block">
&gt;&gt;&gt; class Project(PolymorphicModel):
</pre>
Expand Down
43 changes: 30 additions & 13 deletions CHANGES.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,21 +3,36 @@
Changelog
++++++++++

2010-11-01 V1.0 Beta 2
2010-11-11 V1.0 Beta 2
======================

This is a V1.0 Beta/Testing Release
-----------------------------------
This is a V1.0 Testing Release
------------------------------

Beta 2 accumulated somewhat more changes than intended. It's still
intended for testing and development environments and not for production
(it's best to wait for the final V1.0 for production servers).
Beta 2 accumulated somewhat more changes than intended, and also
has been delayed by DBMS benchmark testing I wanted to do on model
inheritance. These benchmarks show that there are considerable
problems with concrete model inheritance and contemporary DBM systems.
The results will be forthcoming on the google discussion forum.

New Features and API changes since Beta 1
-----------------------------------------
Please also see:
http://www.jacobian.org/writing/concrete-inheritance/

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. No complaints have been heard regarding Beta 1 however,
and Beta 1 is used on a few production sites by some enterprising users.

There will be a release candidate for V1.0 in the very near future.


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 an
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
Expand All @@ -27,7 +42,7 @@ New Features and API changes since Beta 1
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...`` also produces more informative output for custom
``ShowField...`` now also produces more informative output for custom
primary keys.

* ``.non_polymorphic()`` queryset member function added. This is preferable to
Expand Down Expand Up @@ -58,6 +73,7 @@ Bugfixes
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.


------------------------------------------------------------------
Expand Down Expand Up @@ -134,9 +150,10 @@ works correctly with polymorphic models (for all supported versions of Django).

**Output of Queryset or Object Printing**

In order to improve compatibility with vanilla Django, printing quersets does not use
django_polymorphic's pretty printing by default anymore.
To get the old behaviour when printing querysets, you need to replace your model definition:
In order to improve compatibility with vanilla Django, printing quersets
(__repr__ and __unicode__) does not use django_polymorphic's pretty printing
by default anymore. To get the old behaviour when printing querysets,
you need to replace your model definition:

>>> class Project(PolymorphicModel):

Expand Down
Loading

0 comments on commit ca329ff

Please sign in to comment.