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
-
7
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Leap:15.2:FactoryCandidates/python-SQLAlchemy && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
SQLAlchemy-1.4.36.tar.gz | 0008146415 7.77 MB | |
SQLAlchemy.keyring | 0000002176 2.13 KB | |
python-SQLAlchemy.changes | 0000245139 239 KB | |
python-SQLAlchemy.spec | 0000003373 3.29 KB |
Revision 96 (latest revision is 117)
- update to 1.4.36: * details on https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.36 * Fixed regression where the change made for #7861, released in version 1.4.33, that brought the Insert construct to be partially recognized as an ORM-enabled statement * Modified the DeclarativeMeta metaclass to pass cls.__dict__ into the declarative scanning process to look for attributes, rather than the separate dictionary passed to the type’s __init__() method * Fixed a memory leak in the C extensions which could occur when calling upon named members of Row when the member does not exist under Python 3 * Added a warning regarding a bug which exists in the Result.columns() method when passing 0 for the index in conjunction with a Result that will return a single ORM entity, which indicates that the current behavior of Result.columns() is broken in this case as the Result object will yield scalar values and not Row objects * Fixed bug where ForeignKeyConstraint naming conventions using the referred_column_0 naming convention key would not work if the foreign key constraint were set up as a ForeignKey object rather than an explicit ForeignKeyConstraint object.
Comments 0