<% header(name + ' 0.8 Release Notes') %>

<p>Webware for Python 0.8</p>

<a id="Changes"></a><h2>Changes</h2>

<ul>

<li><p>The ObjectStore keeps track of new objects, modified objects and

to-be-deleted objects on a per-thread basis. This prevents the ObjectStore

from trying to save the same changes twice, and prevents the situation where

one thread commits an object which a different thread modified (and wasn't

necessarily ready to commit).</p>

<p>This new tracking is enabled when your ObjectStore is in "Threaded" mode,

which is enabled by default. You can run in single-threaded mode by adding

the following line to the Settings.config file in your model directory:</p>

<pre>'Threaded': 0,</pre>

<p>The behaviour of the following methods has changed:</p>

<ul>

<li>saveChanges() - commits only objects which were modified by the current thread</li>

</ul>

<p>New ObjectStore methods:</p>

<ul>

<li>hasChangesForCurrentThread() - returns whether the store has any

uncommitted changes for the current thread</li>

<li><p>saveAllChanges() - commits <b>all</b> added/modified/deleted objects

to the database, regardless of which thread made the changes. This could

be called on application exit just to be extra safe.</p>

<p>When using MiddleKit from WebKit, though, you be calling saveChanges()

at the end of any request which modifies MK objects, so I recommend putting</p>

<pre class="py">assert not store.hasChangesForCurrentThread()</pre>

<p>into your SitePage.sleep() method to catch programming errors early.</p></li>

</ul>

<p>For <b>upgrading older MiddleKit applications</b>, you'll probably want to

replace calls to store.hasChanges() with store.hasChangesForCurrentThread().

Nothing else should need to change.</p></li>

<li>A new 'Database' setting in Settings.config. Set this if the model name

isn't the same as the database name.</li>

<li>Also, the database name can be passed via the constructor. See the

<a href="UsersGuide.html#MT_DatabaseName">User's Guide</a> for more info.</li>

<li><p>Support for the SQL 'decimal' type, previously found only in the MSSQL

adapter, has been brought up to the generic SQL adapter level which means that

MySQL inherits it. Use the attribute keys <span class="name">Precision</span>

and <span class="name">Scale</span> to specify the precision and scale just

like you see in SQL manuals: decimal(precision, scale).</p>

<p>If (and only if!) you have "legacy" code from the old decimal support, you

could enable the <span class="name">UseMaxForDecimalPrecision</span> setting.

However, you might get fried down the road when MiddleKit starts enforcing

min/max constraints on decimal types. (Getting fried implies you would have

to edit/fix your model.)</p></li>

<li><p>"Dangling obj refs" now print much more useful information. The old message:</p>

<pre class="py">WARNING: Obj ref dangles. dec=266287972390 hex=3e00000026 class.obj=Stop.97.</pre>

<p>The new message:</p>

<pre class="py">WARNING: MiddleKit: In object &lt;PendingTrade 'TIVO long 4.25' 129&gt;, attribute

Trade.initialStop dangles with value Stop.97</pre>

<p>In other words:</p>

<pre class="py">WARNING: MiddleKit: In object <b>&lt;REPR()&gt;</b>, attribute

<b>FULL ATTR NAME</b> dangles with value <b>CLASS.SERIAL_NUM VALUE</b></pre></li>

<li>The <span class="filename">Classes.csv</span> text file is now cached as a

binary pickle file named <span class="filename">Classes.pickle.cache</span>.

This reduces subsequent load times by about 40%. The cache will be ignored

if it can't be read, is older than the CSV file, has a different Python

version, etc. You don't normally even need to think about this, but if for

some reason you would like to turn off the use of the cache, you can do so

via the <span class="name">UsePickledClassesCache</span>

<a href="UsersGuide.html#Configuration">setting</a>.</li>

</ul>

<% footer() %>