Database Abstraction Library

Edit Package python-SQLAlchemy

SQLAlchemy is an Object Relational Mappper (ORM) that provides a flexible,
high-level interface to SQL databases. Database and domain concepts are
decoupled, allowing both sides maximum flexibility and power. SQLAlchemy
provides a powerful mapping layer that can work as automatically or as manually
as you choose, determining relationships based on foreign keys or letting you
define the join conditions explicitly, to bridge the gap between database and
domain.

Refresh
Refresh
Source Files
Filename Size Changed
SQLAlchemy-1.4.42.tar.gz 0008303728 7.92 MB
SQLAlchemy.keyring 0000002176 2.13 KB
python-SQLAlchemy.changes 0000267347 261 KB
python-SQLAlchemy.spec 0000003303 3.23 KB
Revision 101 (latest revision is 119)
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) accepted request 1030996 from Matej Cepl's avatar Matej Cepl (mcepl) (revision 101)
- update to version 1.4.42:
  * orm
    + The Session.execute.bind_arguments dictionary is no longer
      mutated when passed to Session.execute() and similar; instead,
      it’s copied to an internal dictionary for state changes. Among
      other things, this fixes and issue where the “clause” passed to
      the Session.get_bind() method would be incorrectly referring to
      the Select construct used for the “fetch” synchronization
      strategy, when the actual query being emitted was a Delete or
      Update. This would interfere with recipes for “routing
      sessions”.  References: #8614
    + A warning is emitted in ORM configurations when an explicit
      remote() annotation is applied to columns that are local to the
      immediate mapped class, when the referenced class does not
      include any of the same table columns. Ideally this would raise
      an error at some point as it’s not correct from a mapping point
      of view.  References: #7094
    + A warning is emitted when attempting to configure a mapped class
      within an inheritance hierarchy where the mapper is not given
      any polymorphic identity, however there is a polymorphic
      discriminator column assigned. Such classes should be abstract
      if they never intend to load directly.  References: #7545
    + Fixed regression for 1.4 in contains_eager() where the “wrap in
      subquery” logic of joinedload() would be inadvertently triggered
      for use of the contains_eager() function with similar statements
      (e.g. those that use distinct(), limit() or offset()), which
      would then lead to secondary issues with queries that used some
      combinations of SQL label names and aliasing. This “wrapping” is
      not appropriate for contains_eager() which has always had the
      contract that the user-defined SQL statement is unmodified with
Comments 0
openSUSE Build Service is sponsored by