<% 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() %>
