Hi, Actually, this is useful in case of migration from RDBMS where you have multiple tables in the same schema. And if you don't want to amend queries specifying cache name explicitly then one cache with multiple instances (tables) is a very convenient way to go, especially in the case of a very large set of queries. I know at least about one such case.
Kind regards, Alex. On Thu, Apr 20, 2017 at 12:26 AM, Christos Erotocritou < [email protected]> wrote: > I've not come across a case where we used multiple tables per cache and > generally advise against it. Because it is allowed I have though witnessed > cases where users at an early stage use one cache for multiple entities and > ended up confused. From a users stand point I would agree with Vlad to > remove this. > > C. > > > On 19 Apr 2017, at 21:32, Vladimir Ozerov <[email protected]> wrote: > > > > Folks, > > > > Currently we allow multiple SQL tables per cache. This considered a bad > > practice as single cache is getting polluted with unrelated key-value > pairs. > > > > Earlier this use case made sense due to high per-cache overhead and some > > limitation of FairAffinityFunction which cannot guarantee equal partition > > distribution. AFAIK both issues are resolved. > > > > I think we have no reason to allow multiple tables per cache at the > moment. > > If we restrict it to one table we will be able to simplify significantly > > query engine internals and improve performance a bit. Also it aligns > nicely > > with upcoming CREATE TABLE feature. > > > > What do you think about this change? > > > > Vladimir. >
