refactor: add transaction handling in auto CRUD controller

[krzys13]

#277
Add transaction usage in all methods of auto crud controlle.
There is need to add transactions in 'user managment API'
Should I apply trnsactions in seeders, and scrappers also?

[github-actions]

Looks like you did not link an issue to this PR. If this PR completes a task, consider linking it.

[czaja307]

i found one more place that could use transactions - otherwise seems good 🔥

i don't thing we need transactions on seeders or scrappers as they are only used once without much concurrency risc

[krzys13]

We need to discuss

1. Isolations levels fot querries
2. How to implement transactions in validators, Validators operate on http body{request} not on specific model instance.

[mini-bomba]

for isolation levels, i'd suggest repeatable read

to implement transactions in the foreign key validator, i'd suggest passing in the trx object via validation metadata

[krzys13]

for isolation levels, i'd suggest repeatable read

to implement transactions in the foreign key validator, i'd suggest passing in the trx object via validation metadata

Isolations are done
Validation still not

[krzys13]

I don't think this validator should exist here, because it only validates the existence of a foreign key.

This seems to already be handled by the oneToOneRelationStore method:

/**
 * Create a related object for 1:1 relations
 *
 * Return type set to Promise<unknown> to allow for method overrides
 */
async oneToOneRelationStore(httpCtx: HttpContext): Promise<unknown>

which handles creating the related object during the store flow.

@mini-bomba

[mini-bomba]

I'm pretty sure I've made the validators for related-store operations omit the foreign key field on the related object to be created, so it shouldn't matter whether the field has a foreign key validator or not

the foreign key validator is actually executed in two scenarios:

• for direct store ops of objects with foreign keys
• for related-store ops of related objects with multiple foreign keys (validators for foreign key fields for other relations are still used)

(oh and i guess for updates too)

[krzys13]

I'm pretty sure I've made the validators for related-store operations omit the foreign key field on the related object to be created, so it shouldn't matter whether the field has a foreign key validator or not

the foreign key validator is actually executed in two scenarios:

• for direct store ops of objects with foreign keys
• for related-store ops of related objects with multiple foreign keys (validators for foreign key fields for other relations are still used)

(oh and i guess for updates too)

I think we can close that issue and start another about validator refactor. Should checking fk be only in crud controller for better arch.

[mini-bomba]

resolved