[Modeling-users] [Core & ZModeling] Release 0.8.6

[Sebastien B. <sbi...@us...>]

        Hi all,

  This release is normally the last one of the 0.8 series. It is made of
  bug-fixes, the most important one addresses a possibility for to-many
  snapshots to be out-of-sync. wrt. to the database state. As usual the
  full changelog for that release is enclosed at the end of the message.

  The User's Guide has also been reviewed, corrected and enhanced --many
  thanks to Mario Ruggier for his time and effort on this, this work is
  all his.

  Additionally, I made a few changes on the w3-site
  http://modeling.sf.net ; I'm no web-designer but hopefully you'll find
  it clearer.


Important (I almost forgot, silly me): if you're using the framework in
--------- a long-standing process (being alive for more than 24 hours),
          I strongly suggest that you upgrade your copy and that you do
          NOT set MDL_PERMANENT_DB_CONNECTION (see changelog below) ; I
          have experienced strange behaviour with long-standing
          processes (w/ python2.1 & Zope 2.6, psycopg v1.0.14 and
          1.0.15, and PG server 7.2), such as committed changes being
          correctly issued by the psycopg adaptor but never committed
          within the postgresql server, hence causing the corresponding
          transaction to be *lost* (when this happens, you see a
          postgresql 'idle transaction in progress', never ending until
          the python process itself dies)

  While the exact reason for this problem is not completely clear at the
  moment, it was solved by the new behaviour (which closes the
  connection to the db as soon as no more adaptor channels are opened).

  Please also note that the environment variables have changed and are
  now prefixed w/ 'MDL_' to avoid any name clashes.

      Best regards,


-- S=E9bastien.



------------------------------------------------------------------------
0.8.6 (2002/02/21)
-----

  * doc/

      Committed changes on abstract.tex & UserGuide's CustomObject.tex,
      DefiningaModel.tex and ManipulatingGraphOfObjects.tex on behalf of
      Mario Ruggier who reviewed, corrected and enhanced the
      documentation. Thanks a lot!

      + HomePage/ re-organized (this part is used to generate the w3
        site http://modeling.sourceforge.net)

  * DatabaseContext:

    Fixed: adaptor channels are expected to be closed when any of the
           following operations terminates: fetch
           (ec.objectsWithFetchSpec), insert, update or delete
           (ec.saveChanges). The later (saveChanges()) did not close the
           underlying adaptorChannel.

       (see tests.test_AdaptorLayer.test_01_adaptorChannels_are_closed()
        and DatabaseContext._endTransaction())

  * Database Adaptors:

    + AdaptorChannel API: modified the contract for closeChannel(): an
        already closed adaptor channel should not fail when receiving
        the closeChannel() message --however in this situation
        adaptorChannelDidClose() should not be sent to the
        AdaptorContext.

    + AbstractDBAPI2AdaptorContext.adaptorChannelDidClose(): now closes
      the db-connection when closing the last opened
      AdaptorChannel. This behaviour can be changed by setting the
      environment variable MDL_PERMANENT_DB_CONNECTION.

    + fixed PGAdaptorContext.adaptorChannelDidClose(): do not try to
            rollback a db-connection which has been already closed.

  * DatabaseChannel.cancelFetch(): forgot to close the underlying
    adaptor channel. Fixed.

  * environment variables are now prefixed w/ 'MDL_':
      MDL_POSTGRESQL_SERVER_VERSION, MDL_ENABLE_DATABASE_LOGGING,
      MDL_PREFERRED_PYTHON_POSTGRESQL_ADAPTOR

  * DatabaseContext:

    - fixed arrayFaultForGlobalID() signature which did not follow the
      specification of interfaces.ObjectStoreInterface

    - fixed performChanges(): it was possible for a toMany snapshot
      stored in object Database (responsible for snapshots) to get
      out-of-sync with the database, when an object got no modification
      but in one (or more) of its toMany-relationships. After it
      occured, any other EditingContext was obtaining that out-of-sync
      toMany snapshot and when it was triggered, the framework did try
      to fetch, for the best, an object that still exists but shouldn't
      be related, for the worse an object that was removed from the
      database.  (see also: comments left in the source)

      (specifically tested in:
       test_EC_Global.test_16_toManySnapshotsUpdated)

------------------------------------------------------------------------