this is less efficient, and there are still some cases where
we could combine queries, but we need to first solve the behavioral
issues where relationships loaded for calculations could sometimes be loaded
in an "authorized" state when they should not be. We can improve the
speed/efficiency later, correctness is more important.
* Fix the issue with the order of cases
* Make it pass all tests
* Add a test case for the new feature
---------
Co-authored-by: Andreas Donig <git@innwiese.de>
improvement: set `__union_tag__` constraint in array handlers for unions
fix: sleep to avoid uuidv7 specifity flaky test
test: remove unused variable in tests
* Chore: test loading paginated relationship when tenant is in primary key
Ash is already able to load paginated relationships on multitenant
resources after a create or update action.
However this change specifically test the case of a many to many
relationship where the tenant is included in the primary key of the
joined resources.
Signed-off-by: Davide Briani <davide@briani.dev>
* fix: apply pagination at runtime for non lateral join queries
fix: consider multitenancy when checking if through-join is unique
---------
Signed-off-by: Davide Briani <davide@briani.dev>
Co-authored-by: Zach Daniel <zach@zachdaniel.dev>
* Chore: add tests on loading relationship on multitenant resource
Add tests to verify that relationships can be loaded on multitenant
resources after a create or update action.
Signed-off-by: Davide Briani <davide@briani.dev>
* fix: set tenant in ets data layer when generating aggregates
---------
Signed-off-by: Davide Briani <davide@briani.dev>
Co-authored-by: Zach Daniel <zach@zachdaniel.dev>
fix: properly set default timeout to `:infinity`
this avoids unnecessary processes starting when in the vast majority of cases some external thing is imposing a timeout.
fix: pass down `identity` when doing upserts, for new feature support
This change validates that the `load` statement of bulk operations is
respected when specified, and correctly loads relationships.
Loading relationships with pagination on results for bulk destroys is
still not supported. Indeed, relationships are currently queried using a
lateral join but after the resource deletion has happened, so it looks
like nothing is related.
Signed-off-by: Davide Briani <davide@briani.dev>
Ensure that relationships can be correctly loaded, even with pagination,
on the resources resulting from create, update and delete actions.
Signed-off-by: Davide Briani <davide.briani@secomind.com>
the attribute strategy allowed for overwriting the multitenant attribute
on update. In practice, this can't really happen using any standard pattern
because any record to be updated is read with the tenant context, but it still
represents a small risk (and `schema` based multitenancy would enforce it in this
way anyway, so this is more consistent).