Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
From: Christos Erotocritou <christos@gridgain.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 19 Apr 2017 22:26:05 +0100
Subject: Re: Allow only one SQL table per cache
Message-Id: <72FA13F5-D6FE-4E2B-80A0-57ABB686B3C2@gridgain.com>
References: <CAGt6o8=LPBq_cKDb-A+rrtt6xj6NO08SJnrOK-pydndwEnvmgw@mail.gmail.com>
In-Reply-To: <CAGt6o8=LPBq_cKDb-A+rrtt6xj6NO08SJnrOK-pydndwEnvmgw@mail.gmail.com>
To: dev@ignite.apache.org
archived-at: Wed, 19 Apr 2017 21:26:13 -0000

I've not come across a case where we used multiple tables per cache and gene=
rally 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. =46rom a users stand point I would agree with Vlad to remove t=
his.=20

C.=20

> On 19 Apr 2017, at 21:32, Vladimir Ozerov <vozerov@gridgain.com> wrote:
>=20
> Folks,
>=20
> Currently we allow multiple SQL tables per cache. This considered a bad
> practice as single cache is getting polluted with unrelated key-value pair=
s.
>=20
> 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.
>=20
> 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 nicel=
y
> with upcoming CREATE TABLE feature.
>=20
> What do you think about this change?
>=20
> Vladimir.