* 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).