Improve session handling: Avoid need to commit() before doing a query

Since Engine API holds different session context (Sync Agent & Web App) it's required to do a commit before doing a query. Improve session handling to avoid this.

For example: https://gitlab.servus.at/aura/engine-api/-/blob/master/src/models.py#L81

changed milestone to %1.2

assigned to @david

marked this issue as related to engine#75 (closed)

assigned to @chrizz and unassigned @david

added Doing label

changed milestone to %1.0-alpha3 — Playful Platypus

added 1 deleted label

closed

reopened

mentioned in merge request !24 (merged)

@david Refactored session handling in !24 (diffs) but couldn't verify yet if the multithread-scenario works as expected.

@chrizz You can verify if it's working, when you

• start two engine-api instances (one as sync node, one as main node)
• post e.g. playlogs to the main node, while the sync node is running --> it should also be logged to the sync node
• post e.g. playlogs to the main node, while the sync node is not running --> after the post start the sync node, it should start the background sync job and correctly sync the missing playlog(s) from the main node

If there are not exceptions in the logs and everything synced correctly, you got the session handling right.

Reproduced scenario above - seems to work now after doing some refactoring. There's one thread-related exception left when the database file is not present and must be created first - so merging after fixing that.

@chrizz sounds great. Thank you. Just please consider testing this with Postgres also.

Finally got it running using sqlite, postgres and the federation scenario. Playlog is synced as expected* but there's one issue left I can't explain right now:

Seems like the sync node should init the PlayLog with camelCase keys, while the actual implementation provides snake_case keys. So adding the synced Playlog fails until at least trackStart is defined (which is non-null and thus required for successful committing).

To verify the fix of the multithreaded issue, I added* !24 (27c53f54) as a temp workaround.

So just need to resolve why the camelcase conversion doesn't work automatically - and ideas?

Decided to do the camelCase conversion manually as temp fix in order to finish and close this issue. !24 (bfbd1a1e)

Continuing investigation in #52. Merging now since all tests succeeded - including the multi-node-setup using postgres.

closed

mentioned in commit ea67094d

removed Doing label