Database Abstraction Library
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.
- Developed at devel:languages:python
- Sources inherited from project openSUSE:Factory
-
8
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Backports:SLE-15-SP4:FactoryCandidates/python-SQLAlchemy && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
SQLAlchemy-2.0.15.tar.gz | 0009296612 8.87 MB | |
SQLAlchemy.keyring | 0000002176 2.13 KB | |
python-SQLAlchemy.changes | 0000275405 269 KB | |
python-SQLAlchemy.spec | 0000003613 3.53 KB |
Revision 107 (latest revision is 119)
Dominique Leuenberger (dimstar_suse)
accepted
request 1089853
from
Daniel Garcia (dgarcia)
(revision 107)
- Switch documentation to be within the main package. - Update to 2.0.15 # orm * As more projects are using new-style “2.0” ORM querying, it’s becoming apparent that the conditional nature of “autoflush”, being based on whether or not the given statement refers to ORM entities, is becoming more of a key behavior. Up until now, the “ORM” flag for a statement has been loosely based around whether or not the statement returns rows that correspond to ORM entities or columns; the original purpose of the “ORM” flag was to enable ORM-entity fetching rules which apply post-processing to Core result sets as well as ORM loader strategies to the statement. For statements that don’t build on rows that contain ORM entities, the “ORM” flag was considered to be mostly unnecessary. * It still may be the case that “autoflush” would be better taking effect for all usage of Session.execute() and related methods, even for purely Core SQL constructs. However, this still could impact legacy cases where this is not expected and may be more of a 2.1 thing. For now however, the rules for the “ORM-flag” have been opened up so that a statement that includes ORM entities or attributes anywhere within, including in the WHERE / ORDER BY / GROUP BY clause alone, within scalar subqueries, etc. will enable this flag. This will cause “autoflush” to occur for such statements and also be visible via the ORMExecuteState.is_orm_statement event-level attribute. References: #9805 # postgresql * Repaired the base Uuid datatype for the PostgreSQL dialect to
Comments 0