Can we make cache-per-table a requirement only for CREATE TABLE command? Not sure why would we have to prohibit the current behavior.
On Wed, Apr 19, 2017 at 4:15 PM, Denis Magda <[email protected]> wrote: > 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. > >> > >
