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 > > >
