HI all,
+1 for "table" from me. For me "table" has several benefits:
1. It's common and consequently easy to explain and understand.
2. It's quite universal. One can worry that "table" does not describes
key-value storage well.
I don't see any problem here, because Hash Table data structure
contains "table" word it it's name.
Also DHT comes to mind. Internally we have GridDhtCache class. So it's
already a "table".
Regarding multiple QueryEntities in single cache. Correct me if I am wrong,
but currently we do not recommend to use them.
чт, 18 окт. 2018 г. в 15:18, David Harvey <syssoft...@gmail.com>:
> We had a terminology agreement early on where we agreed to call them
> caches, but we still call them tables anyway.
>
> When I finally understood how you could have multiple tables in a single
> cache, I tried to find example use cases, but couldn't. Is there even a
> test with multiple queryEntities?
>
> On Thu, Oct 18, 2018, 8:10 AM Alexey Zinoviev <zaleslaw....@gmail.com>
> wrote:
>
> > From my perspective (ML module), it will be very easy to talk about
> Ignite
> > in SQL terms like table (with additional information about ability to
> make
> > key-value CRUD operations, not only SELECT * FROM Table)
> > Also we could look on PostgreSQL with different plugins for SQL extension
> > like PostGIS or support of JSON-B and ability to store not only planar
> data
> > with strict schema (I agrre here with Vladimir).
> >
> > чт, 18 окт. 2018 г. в 14:33, Ilya Lantukh <ilant...@gridgain.com>:
> >
> > > I thought that current "caches" and "tables" have 1-to-N relation. If
> > > that's not a problem, than I also think that "table" is the best term.
> > >
> > > On Thu, Oct 18, 2018 at 9:29 AM Vladimir Ozerov <voze...@gridgain.com>
> > > wrote:
> > >
> > > > Well, I never thought about term “table” as a replacement for
> “cache”,
> > > but
> > > > it appears to be good candidate.
> > > >
> > > > This is used by many some major vendors whose underlying storage is
> > > indeed
> > > > a kind of key-value data structure. Most well-known example is MySQL
> > with
> > > > its MyISAM engine. Table can be used for both fixed and flexible
> (e.g.
> > > > JSON) schemas, as well as key-value access (hash map -> hash table,
> > both
> > > > are good).
> > > >
> > > > Another important thing - we already use term “table”, and it is
> always
> > > > hard to explain our users how it relates to “cache”. If “cache” is
> > > dropped,
> > > > then a single term “table” will be used everywhere.
> > > >
> > > > Last, but not least - “table” works well for both in-memory and
> > > persistent
> > > > modes.
> > > >
> > > > So if we are really aim to rename “cache”, then “table” is the best
> > > > candidate I’ve heard so far.
> > > >
> > > > чт, 18 окт. 2018 г. в 8:40, Alexey Zinoviev <zaleslaw....@gmail.com
> >:
> > > >
> > > > > Or we could extend our SQL commands by "GET BY KEY = X" and "PUT
> (x1,
> > > x2,
> > > > > x3) BY KEY = X" and the IgniteTable could be correct.
> > > > > Agree with Denis that each table in the 3rd normal form is like
> > > key-value
> > > > > store. Key-value operations are only subset of rich SQL commands.
> > > > >
> > > > > The problem with IgniteData that it's too common. Also, it's
> > difficult
> > > to
> > > > > understand is it a plural or single object? For instance, the bunch
> > of
> > > > > IgniteTables could be IgniteData. But the set of IgniteData?
> > > IgniteDatum?
> > > > >
> > > > >
> > > > >
> > > > > чт, 18 окт. 2018 г. в 4:18, Denis Magda <dma...@apache.org>:
> > > > >
> > > > > > Key-value calls are just primary key based calls. From a user
> > > > > perspective,
> > > > > > it's the same as "SELECT * FROM table WHERE primary_idx = X",
> just
> > > > > > different API.
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > > On Wed, Oct 17, 2018 at 5:04 PM Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Wed, Oct 17, 2018 at 4:58 PM Denis Magda <dma...@apache.org
> >
> > > > wrote:
> > > > > > >
> > > > > > > > I've been calling everything "tables" instead of "caches"
> for a
> > > > > while.
> > > > > > > The
> > > > > > > > main reason is the maturity of our SQL engine - seeing more
> SQL
> > > > users
> > > > > > and
> > > > > > > > deployments which talk "tables" language.
> > > > > > > >
> > > > > > > >
> > > > > > > I think "IgniteTable" only implies SQL, not key-value. We need
> > > both.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ilya
> > >
> >
>
--
Best regards,
Ivan Pavlukhin
