Table of Contents
GINO does perform the Object-Relational Mapping work under the Data Mapper Pattern, but it is just not a traditional ORM. The Objects in GINO are completely stateless from database - they are pure plain Python objects in memory. Changing their attribute values does not make them “dirty” - or in a different way of thinking they are always “dirty”. Any access to database must be explicitly executed. Using GINO is more like making up SQL clauses with Models and Objects, executing them to make changes in database, or loading data from database and wrapping the results with Objects again. Objects are just row data containers, you are still dealing with SQL which is represented by Models and SQLAlchemy core grammars. Besides GINO can be used in a completely non-ORM way.
GINO invented none about making up queries, everything for that is inherited from SQLAlchemy. Therefore you just need to know how to write join in SQLAlchemy. Especially, Ádám made some amazing upgrades in GINO #113 to make join easier, so that you can use model classes directly as if they are tables in joining:
results = await User.join(Book).select().gino.all()
engine = await gino.create_engine(..., ssl=True)
It is a partial backport of the new built-in module contextvars introduced in Python
3.7. In Python 3.5 and 3.6,
to copy context from caller as a workaround to simulate the same behavior. This
is also under discussion in upstream backport project, please read more here:
If you are using Python 3.7, then
aiocontextvars does nothing at all.
This answer is for GINO 0.8 and later, please check earlier versions of this documentation if you are using GINO 0.7.