Alex F., Once we introduce true “schema name” as a part of DDL activities this will no longer be an issue. Presently, you use “single-cache->multiple-types(tables)” as a workaround to simplify development.
In general, I’m in the same boat with Chris - didn’t see production use cases that leveraged from this feature. Vovan, I hope we can rework this in 2.1, if the consensus is achieved, right? I would encourage us to stop stuffing 2.0 with minor changes :) It’s time to pass it on to QA. — Denis > On Apr 19, 2017, at 2:34 PM, Alexander Fedotov <[email protected]> > wrote: > > 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. >>
