> My intention was to separate the local and shared query caches while not
> eliminating either, so that is the reason both are used. So if you have
> explicitly set a custom localQueryCache then calling getQueryCache() will
> allow you to still access the *shared* query cache as well.
But this is
As deprecating SelectQuery has been on my TODO list for some time, let me share
my thoughts... The motivation for the change is of course that we don't want to
support two styles of queries at the same time. We are not a big team, and
having the smallest possible maintenance footprint is importa
Thanks for comments.
Seems that there are no disagreements to mark SelectQuery as deprecated.
So I'll merge this PR.
On Thu, Jul 4, 2019 at 11:42 AM Andrus Adamchik
wrote:
> As deprecating SelectQuery has been on my TODO list for some time, let me
> share my thoughts... The motivation for the ch
On Thu, Jul 4, 2019 at 2:45 AM Andrus Adamchik
wrote:
> > My intention was to separate the local and shared query caches while not
> > eliminating either, so that is the reason both are used. So if you have
> > explicitly set a custom localQueryCache then calling getQueryCache() will
> > allow yo
> I think that would be too limiting. I would prefer to be able to use caches
> with both behavoirs/lifecycles in the same context.
Could you please elaborate on use cases?
> The choice of the scope or lifetime of the cache should be at the query level
> rather than the context level.
But yo
