Beta 4 of SQLAlchemy 0.7 has been released. This is most likely the last beta 
of version 0.7 before final release. 0.7 has been downloaded many hundreds of 
times and a small series of regressions have been fixed; it is used in at least 
a few production installations already.

Of particular note in this release:

- Support for psycopg2, the Postgresql driver, on Python 3
- The C extensions now build by default for the Python 2 platform.
- Support for Python 3 builds using plain Python Distutils, or Distribute.
- Full test success for Pypy, Python 3.2
- Lots of bugfixes and revised documentation, including the new revised index 
page: http://www.sqlalchemy.org/docs/07/

0.7beta4 owes a lot to the sprinters at this year's Pycon; a subsequent blog 
post detailing the sprints for this year is coming soon.

The SQLAlchemy 0.7 series represents a great leap forward in functionality and 
performance - the upgrade path starts by reviewing the 07Migration document at 
http://www.sqlalchemy.org/trac/wiki/07Migration .

Download SQLAlchemy 0.7beta4 at: http://www.sqlalchemy.org/download.html

0.7.0b4
=======
- general
  - Changes to the format of CHANGES, this file.
    The format changes have been applied to 
    the 0.7 releases.

    - The "-declarative" changes will now be listed
      directly under the "-orm" section, as these
      are closely related.

    - The 0.5 series changes have been moved to
      the file CHANGES_PRE_06 which replaces
      CHANGES_PRE_05.

    - The changelog for 0.6.7 and subsequent within
      the 0.6 series is now listed only in the 
      CHANGES file within the 0.6 branch.  
      In the 0.7 CHANGES file (i.e. this file), all the
      0.6 changes are listed inline within the 0.7
      section in which they were also applied 
      (since all 0.6 changes are in 0.7 as well).
      Changes that apply to an 0.6 version here
      are noted as are if any differences in 
      implementation/behavior are present.

- orm
  - Some fixes to "evaulate" and "fetch" evaluation
    when query.update(), query.delete() are called.
    The retrieval of records is done after autoflush
    in all cases, and before update/delete is 
    emitted, guarding against unflushed data present
    as well as expired objects failing during 
    the evaluation.  [ticket:2122]

  - Reworded the exception raised when a flush
    is attempted of a subclass that is not polymorphic
    against the supertype.  [ticket:2063]

  - Still more wording adjustments when a query option
    can't find the target entity.  Explain that the
    path must be from one of the root entities.

  - Some fixes to the state handling regarding 
    backrefs, typically when autoflush=False, where
    the back-referenced collection wouldn't 
    properly handle add/removes with no net 
    change.  Thanks to Richard Murri for the 
    test case + patch.  [ticket:2123]
    (also in 0.6.7).

  - Added checks inside the UOW to detect the unusual
    condition of being asked to UPDATE or DELETE
    on a primary key value that contains NULL
    in it.  [ticket:2127]

  - Some refinements to attribute history.  More
    changes are pending possibly in 0.8, but
    for now history has been modified such that
    scalar history doesn't have a "side effect"
    of populating None for a non-present value.
    This allows a slightly better ability to 
    distinguish between a None set and no actual 
    change, affects [ticket:2127] as well.

  - a "having" clause would be copied from the
    inside to the outside query if from_self()
    were used; in particular this would break
    an 0.7 style count() query [ticket:2130].
    (also in 0.6.7)

  - the Query.execution_options() method now passes
    those options to the Connection rather than
    the SELECT statement, so that all available
    options including isolation level and 
    compiled cache may be used.  [ticket:2131]

- sql
  - The "compiled_cache" execution option now raises
    an error when passed to a SELECT statement 
    rather than a Connection.  Previously it was
    being ignored entirely.   We may look into
    having this option work on a per-statement
    level at some point. [ticket:2131]

  - Restored the "catchall" constructor on the base
    TypeEngine class, with a deprecation warning.
    This so that code which does something like
    Integer(11) still succeeds.

  - Fixed regression whereby MetaData() coming
    back from unpickling did not keep track of 
    new things it keeps track of now, i.e.
    collection of Sequence objects, list
    of schema names.  [ticket:2104]

  - The limit/offset keywords to select() as well
    as the value passed to select.limit()/offset()
    will be coerced to integer.  [ticket:2116]
    (also in 0.6.7)

  - fixed bug where "from" clause gathering from an
    over() clause would be an itertools.chain() and
    not a list, causing "can only concatenate list"
    TypeError when combined with other clauses.

  - Fixed incorrect usage of "," in over() clause
    being placed between the "partition" and "order by"
    clauses.  [ticket:2134]

  - Before/after attach events for PrimaryKeyConstraint
    now function, tests added for before/after events
    on all constraint types.  [ticket:2105]

  - Added explicit true()/false() constructs to expression
    lib - coercion rules will intercept "False"/"True"
    into these constructs.  In 0.6, the constructs were
    typically converted straight to string, which was 
    no longer accepted in 0.7.  [ticket:2117]

- engine
  - The C extension is now enabled by default on CPython
    2.x with a fallback to pure python if it fails to
    compile.  [ticket:2129]

- schema
  - The 'useexisting' flag on Table has been superceded
    by a new pair of flags 'keep_existing' and 
    'extend_existing'.   'extend_existing' is equivalent
    to 'useexisting' - the existing Table is returned,
    and additional constructor elements are added.
    With 'keep_existing', the existing Table is returned,
    but additional constructor elements are not added -
    these elements are only applied when the Table
    is newly created.   [ticket:2109]

- types
  - REAL has been added to the core types.  Supported
    by Postgresql, SQL Server, MySQL, SQLite.  Note
    that the SQL Server and MySQL versions, which 
    add extra arguments, are also still available
    from those dialects.  [ticket:2081]

-event
  - Added @event.listens_for() decorator, given
    target + event name, applies the decorated 
    function as a listener.  [ticket:2106]

- pool
  - AssertionPool now stores the traceback indicating
    where the currently checked out connection was
    acquired; this traceback is reported within
    the assertion raised upon a second concurrent 
    checkout; courtesy Gunnlaugur Briem 
    [ticket:2103]

  - The "pool.manage" feature doesn't use pickle
    anymore to hash the arguments for each pool.

- sqlite
  - Fixed bug where reflection of foreign key
    created as "REFERENCES <tablename>" without
    col name would fail.  [ticket:2115]
    (also in 0.6.7)

- postgresql
  - Psycopg2 for Python 3 is now supported.

  - Fixed support for precision numerics when using
    pg8000. [ticket:2132]

- oracle
  - Using column names that would require quotes
    for the column itself or for a name-generated
    bind parameter, such as names with special
    characters, underscores, non-ascii characters,
    now properly translate bind parameter keys when
    talking to cx_oracle.  [ticket:2100]  (Also
    in 0.6.7)

  - Oracle dialect adds use_binds_for_limits=False
    create_engine() flag, will render the LIMIT/OFFSET
    values inline instead of as binds, reported to
    modify the execution plan used by Oracle.
    [ticket:2116] (Also in 0.6.7)

- documentation
  - Documented SQLite DATE/TIME/DATETIME types.
    [ticket:2029] (also in 0.6.7)

  - Fixed mutable extension docs to show the 
    correct type-association methods.
    [ticket:2118]

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to