SQLAlchemy and Imperative Mapping (a.k.a. Classical Mapping)

[AdrianB-sovo]

In chapter 02, it's stated that the classical mapping is an alternative to the declarative mapping and that:

This gives us all the benefits of SQLAlchemy

See here: https://github.com/cosmicpython/book/blob/master/chapter_02_repository.asciidoc#inverting-the-dependency-orm-depends-on-model

But, in the SQLAlchemy documentation about Imperative/Classical Mapping, the following is stated:

The imperative mapping form is a lesser-used form of mapping that originates from the very first releases of SQLAlchemy in 2006. It’s essentially a means of bypassing the Declarative system to provide a more “barebones” system of mapping, and does not offer modern features such as PEP 484 support. As such, most documentation examples use Declarative forms, and it’s recommended that new users start with Declarative Table configuration.

(Emphasis mine)

The content of this chapter should probably be modified to indicate that. Also, is there an alternative that would use the recommended Declarative mapping?

[hjwp]

as far as i know the only alternative is to have your domain model classes become sqlalchemy classes, effectively tightly coupling your domain with sqlalchemy. so as always, it's a trade-off...

[hjwp]

nice to see the classical mappers still exist in v2 tho, i was worried they were gone completely. i should upgrade....

[Bryant-Yang]

The data class might be dataclass, attrs or pydantic, all are more general and framework independent, easy to write business logic with or without sqlalchemy or even relational database.