I cast my vote for the "table". This term is generic, well-understood and
naturally fits SQL-intensive use cases. Basically, we don't need to
reinvent the wheel and the "table" aligns with our internal storage
structure proposed for 3.0.
Vladimir Ozerov's thoughts down below this discussion thread
Igniters,
I would like to resurrect this discussion, as we have a chance to make the
change in Ignite 3.0.
The 'cache' term is clearly outdated and does not describe the
functionality of Ignite. It looks like the term 'table' got the most
support so far, and I think it quite accurately describes
I am beginning to like IgniteTable as well. How would something like this
be introduced to Ignite? Would we have IgniteTable extend IgniteCache? What
would happen to cache groups?
D.
On Thu, Oct 18, 2018 at 7:58 AM Павлухин Иван wrote:
> HI all,
>
> +1 for "table" from me. For me "table" has se
On Thu, Oct 18, 2018 at 5:18 AM David Harvey wrote:
> 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
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
co
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?
O
>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 s
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
wrote:
> Well, I never thought about term “table” as a replacement for “cache”, but
> it appears to be good
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
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 th
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
wrote:
> On Wed, Oct 17, 2018 at 4:58 PM Denis Magda wrote:
>
> > I've been ca
On Wed, Oct 17, 2018 at 4:58 PM Denis Magda 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 k
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.
On Wed, Oct 17, 2018 at 3:55 PM Dmitriy Setrakyan
wrote:
> If dataset cannot be used, can we still consi
If dataset cannot be used, can we still consider "IgniteData"?
D.
On Wed, Oct 17, 2018 at 5:06 AM Ilya Lantukh wrote:
> As I see, many people agree that the term *"cache"* is outdated, but
> consider these changes too disruptive.
>
> For me, keeping terminology up-to-date is important part of p
As I see, many people agree that the term *"cache"* is outdated, but
consider these changes too disruptive.
For me, keeping terminology up-to-date is important part of project
development. If we change some of our core terms with more relevant ones,
it indeed might cause confusion for current user
Unfortunately, we already use the word *"store"* for many other concepts,
like CacheStore and PageStore. I'd prefer to avoid giving it one more
meaning.
As already mentioned, *"dataset"* has special meaning for ML folks.
*"Bucket" *might give wrong association with bucket in a hash table.
On Wed
Well, the obvious term for me is a "Store" or "MemoryStore", as we already
have persistence store.
Best Regards,
Igor
On Wed, Oct 17, 2018 at 1:19 PM Andrey Kuznetsov wrote:
> I'm not an ML expert, so 'dataset' term just reminds me of various client
> drivers to access tables from RDBM servers
I'm not an ML expert, so 'dataset' term just reminds me of various client
drivers to access tables from RDBM servers. For me, the only common trait
of all kinds of Ignite caches is their asociativity. So if we rename them
I'd suggest something like KVStore.
ср, 17 окт. 2018 г. в 12:56, Alexey Zino
>From my perspective, the main goal is to make easy the explanation what is
Ignite on conferences, marketing deals, in papers, in documentation. And the
/cache/ term really reduces the area of Ignite usage in users minds.
I don't support the critical changes in code base, but I support all changes
I'm sorry, but the IgniteDataset can not be used like a basic term, due to
it's ML specific term and also we have a few kind of datasets (that are not
equivalents of IgniteCache/Space and etc) like IgniteDataset,
PartitionBasedDataset, LocalCachedDataset and so on.
Of course, we could find a datas
“tablespace”.
>
> I have to say I never heard of JavaSpaces :) Don’t think many people will
> recall that.
>
> Stan
>
> From: Dmitriy Setrakyan
> Sent: 16 октября 2018 г. 20:21
> To: dev
> Subject: Re: Applicability of term 'cache' to Apache Ignite
>
> Al
Setrakyan
Sent: 16 октября 2018 г. 20:21
To: dev
Subject: Re: Applicability of term 'cache' to Apache Ignite
Although I agree that this change is disruptive, can we just entertain
Ilya's idea for a bit? What if we were designing Ignite from scratch, what
different name would we give to
Although I agree that this change is disruptive, can we just entertain
Ilya's idea for a bit? What if we were designing Ignite from scratch, what
different name would we give to the IgniteCache abstraction? Ilya suggested
"IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
[1
Agree with Vladimir here.
Let's stick to the "principle of least astonishment" - all current users
will be surprised if we'll rename IgniteCache, new users won't be
greatly surprised due to compliance with JCache.
Best Regards,
Ivan Rakov
On 16.10.2018 15:53, Vladimir Ozerov wrote:
What is
To me it seems that usage of term *"cache" *restricts adoption of Apache
Ignite as a primary data storage. If I didn't know anything about internal
implementation, storing critical data in IgniteCache would make me feel
that I'm doing something wrong. Of course it's just my point of view, and
thing
What is the ultimate goal of all these changes? While I agree that term
"cache" might be a bit outdated at the moment, there is nothing
fundamentally wrong with - data is still being cached in memory with an
option to persist it on disk. We should remember, that legacy and previous
user experience
How about separating our JCache implementation from the core of the probuct.
Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
At the same time, it is the direct implementation of the JCache API,
and some of the JCache features align somewhat awkwardly with Ignite concept
27 matches
Mail list logo
