You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to implement explicit row-level lock on SELECT queries and can't find out the best way to reset it.
It seems that RelationProxy never resets query and there is no way to do this manually. This means once a row-locking method is called, every subsequent all/first/last will lock rows to. By the way, code like this gets confusing to:
auto rp = RelationProxy!User(conn);
auto users1 = rp.where(["someData": 123]).all;
auto users2 = rp.where(["someOtherData": 456]).all;
users2 will contain users filtered by both someData = 123 AND someOtherData = 456 rather than just someOtherData = 456. It is somewhat confusing, and there also no way to reset someData = 123 filter except for reinitialize rp.
On the other hand, RelationMixin will create new RelationProxy instance every time struct/class calls an ORM method. In this case filters and row-locks are reset on each ORM method call. But in cost of creating a new instance of RelationProxy and destroying cached content of previous RelationProxy instance.
So my questions are:
Perhaps where called on a RelationProxy should reset filters (and other SELECT parameters, such as LIMIT, OFFSET, ORDER, row-level lock, etc.), and for current behavior use and method on RelationProxy explicitly? Or even use a whole chain explicitly, like this:
auto users1 = rp.where(["someData": 123]).all; // will return filtered rowsauto users2 = rp.all; // will return the content of the whole table
Should RelationMixin declare static RelationProxy instance for a class/struct?
The text was updated successfully, but these errors were encountered:
RelationProxy, being an unfinished API is not exactly what I had planned initially.
The current idea is to not change the state in the RelationProxy itself but instead make a copy and modify the state in that. That'll allow you to reuse the same initial instance of multiple times and just build queries on top of that like such:
auto rp = RelationProxy!User;
auto allRows = rp.all;
auto filteredRows = rp.where("row = 1").all;
// and so on
This eliminates all need to reset the state/queries.
The current solution is to use the RelationMixin inside User since each of its methods spawns another instance of RelationProxy.
But this approach renders caching unusable since in the case of copying the initial RelationProxy it will always be marked as 'stale'. Or rather difficult to make a RelationProxy to track if the new chain can use cached data from the previous one. Besides, user can easily make his/her own cache like this:
auto rp = RelationProxy!User;
auto cachedUsers = rp.all;
Should the caching be maintained somehow or be just removed from the RelationProxy?
I am trying to implement explicit row-level lock on SELECT queries and can't find out the best way to reset it.
It seems that RelationProxy never resets query and there is no way to do this manually. This means once a row-locking method is called, every subsequent
all
/first
/last
will lock rows to. By the way, code like this gets confusing to:users2 will contain users filtered by both
someData = 123 AND someOtherData = 456
rather than justsomeOtherData = 456
. It is somewhat confusing, and there also no way to resetsomeData = 123
filter except for reinitializerp
.On the other hand, RelationMixin will create new RelationProxy instance every time struct/class calls an ORM method. In this case filters and row-locks are reset on each ORM method call. But in cost of creating a new instance of RelationProxy and destroying cached content of previous RelationProxy instance.
So my questions are:
where
called on a RelationProxy should reset filters (and other SELECT parameters, such as LIMIT, OFFSET, ORDER, row-level lock, etc.), and for current behavior useand
method on RelationProxy explicitly? Or even use a whole chain explicitly, like this:The text was updated successfully, but these errors were encountered: