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 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 is of great importance for users. And disruptive changes
such as rename of a basic concept may make adoption of a new versions
harder for users, with very questionable benefits on the other side.
As far as wrappers, personally I do not support this idea. Both "cache" and
"sql" are access methods to some information ("space"), rather than
wrappers around it. Moreover, it is hard to say whether we will have SQL
API at all, because this is big effort with not very clear value, provided
that there are industrial interfaces (JDBC, ODBC).
On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <stanlukya...@gmail.com>
wrote:
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
concepts.
Would be nice to have something like IgniteSpace as our core component,
and have other components built on top of it as wrappers providing various
APIs.
For example
- IgniteSpace itself is a distributed storage unit, that is partitioned,
that has affinity, etc;
note that it doesn’t have to have ANY particular API to add data, even
key-value
- IgniteCache is a wrapper around IgniteSpace that allows to store
key-value pairs and implements JCache API
- IgniteSql (we’re doing it eventually, right?) is a wrapper around
IgniteSpace that allows to store SQL tables and implements ANSI SQL
- IgniteQueue is a wrapper that implements Queue
and so on.
WDYT?
Stan
From: Ilya Lantukh
Sent: 15 октября 2018 г. 14:49
To: dev@ignite.apache.org
Subject: Applicability of term 'cache' to Apache Ignite
Hi Igniters,
I would like to rise a question how we use the term *'cache'* in Ignite and
how it corresponds to terminology in IT industry in general.
From wikipedia:
In computing <https://en.wikipedia.org/wiki/Computing>, a *cache* /kæʃ/
<https://en.wikipedia.org/wiki/Help:IPA/English> *kash*
<https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>, is a
hardware or software component that stores data so that future requests for
that data can be served faster; the data stored in a cache might be the
result of an earlier computation or a copy of data stored elsewhere. [1]
When the first version of Ignite was released, this term was correct. We
positioned Ignite mostly as an intermediate storage layer between
application and a database, designed to make data access faster.
However, since addition of native persistence we started to call Ignite a
"memory-centric database", and as far as I know, some organizations now use
it as a primary data storage, without underlying database. In this case,
calling our storage unit a *'cache'* causes unnecessary confusion.
Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
fit both use-cases.
Personally I like the term IgniteSpace.
[1] https://en.wikipedia.org/wiki/Cache_(computing)
--
Best regards,
Ilya
