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], which is an obsolete technology at this point.
Any other ideas? [1] https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html D. On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov <ivan.glu...@gmail.com> wrote: > 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 > >> > >> > >
