there are two parts to this:
-
at Core, a new execution option log_note is added , allowing arbitrary text to be emitted next to the caching badge:
conn.execute(stmt, execution_options={"log_note": "foobar"})
showing logging like:
2022-02-18 08:45:04,380 INFO sqlalchemy.engine.Engine [generated in 0.00028s] [foobar]
tests go in test/engine/test_logging.py
- in the ORM, add log_notes for secondary loads like eager loaders, lazy loaders , example:
SELECT employee.id AS employee_id, manager.id AS manager_id, employee.type AS employee_type
FROM employee JOIN manager ON employee.id = manager.id
WHERE employee.id IN (?)
2022-02-18 08:45:04,380 INFO sqlalchemy.engine.Engine [caching disabled 0.00028s] [selectinload Engineer.manager] (1,)
for this part there's not a good place in the ORM tests for this. one option is to spread tests across all of test_selectinload, test_lazyload, test_deferred, etc. but this is going to be a lot of disparate tests all over the place, we could make a fixture of some kind, but it's likely best there's one suite that exercises all the individual kinds of logging we want, one test for each kind of log. likely a new suite test/orm/test_logging.py, would have a single class-based fixture similar to ones used in test/engine/test_logging.py, but also including the stock ORM model, then can use @testing.combinations to test all the relationship loaders on one, then a separate set of tests for deferred column loaders.
there are two parts to this:
at Core, a new execution option log_note is added , allowing arbitrary text to be emitted next to the caching badge:
conn.execute(stmt, execution_options={"log_note": "foobar"})
showing logging like:
tests go in test/engine/test_logging.py
for this part there's not a good place in the ORM tests for this. one option is to spread tests across all of test_selectinload, test_lazyload, test_deferred, etc. but this is going to be a lot of disparate tests all over the place, we could make a fixture of some kind, but it's likely best there's one suite that exercises all the individual kinds of logging we want, one test for each kind of log. likely a new suite test/orm/test_logging.py, would have a single class-based fixture similar to ones used in test/engine/test_logging.py, but also including the stock ORM model, then can use
@testing.combinationsto test all the relationship loaders on one, then a separate set of tests for deferred column loaders.