Open Betelgeyser opened 7 years ago
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.
That clarifies a bit.
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:
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 useand
method on RelationProxy explicitly? Or even use a whole chain explicitly, like this:Should RelationMixin declare static RelationProxy instance for a class/struct?