Agree, lets move forward with the simplest possible solution for now. Sergi
2017-04-25 13:07 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > Folks, > > I do not think it is legal to add such property to ConnectorConfiguration. > Connector is a generic gateway to cluster resources. It should not bother > about caches anyhow. What if there are multiple caches in the cluster? What > is I want to access "cache A" from Memcached and "cache B" from Redis > simultaneously? Etc.. This kind of property should be defined on client > level, not on the server. > > For now, provided that 2.0 is about to be freezed, I propose to stick to > Dmitriy's approach and use "default" cache name instead of null. This > should work fine for AI 2.0. We will be able to improve it in further > releases. > > Thoughts? > > Vladimir. > > On Tue, Apr 25, 2017 at 7:22 AM, Roman Shtykh <rsht...@yahoo.com.invalid> > wrote: > > > Igor, +1 from me.We can add a field to ConnectorConfiguration (not sure > if > > it's a proper place, but it's shared by REST, memcached and Redis). A > user > > will have to create a cache, configure as needed and specify the name in > > ConnectorConfiguration. > > Roman > > > > > > > > On Monday, April 24, 2017 10:34 PM, Seliverstov Igor < > > gvvinbl...@gmail.com> wrote: > > > > > > Dear Igniters, > > > > Seems we have almost the same issue with Memcached protocol. > > > > There is an ability to define a cache name via operation extras message > > part ( > > https://github.com/memcached/memcached/wiki/ > BinaryProtocolRevamped#packet- > > structure) > > but it looks a bit complicated from my point of view... > > > > Different client implementations might provide such functionality or not > (I > > mean an additional info in an operation extras), so, potential user might > > have some difficultes using Ignite as a Memcached server because of this > > ignite-specific message part becomes mandatory. > > > > An alternative (an the best way, I think) is introducing a configuration > > property to define which cache to use in case it hasn't be defined in a > > message. > > > > I'll appreciate any thoughts on that. > > > > Regards, > > Igor > > > > 2017-04-24 12:43 GMT+03:00 Roman Shtykh <rsht...@yahoo.com.invalid>: > > > > > Vladimir, > > > Probably we may set the cache name via https://redis.io/commands/ > > > client-setname, save it and use until the user specifies another name. > > > #That will be the name for the default cache (mainly for STRING data). > > For > > > other data types, like hashes (https://redis.io/topics/data-types), I > am > > > thinking about putting data into caches specified by key. > > > Or use https://redis.io/commands/config-set CONFIG SET DFLT_CACHE > > > cache_name,and save cache name somewhere in Ignite cluster (what is the > > > proper place to store such info?). > > > For that, we have to implement one of the above-mentioned commands. > > > What do you think? > > > > > > > > > > > > On Monday, April 24, 2017 4:34 PM, Vladimir Ozerov < > > > voze...@gridgain.com> wrote: > > > > > > > > > Roman, > > > Is it possible to define a kind of property in Redis connection string > > (or > > > property map) for this purpose? IMO ideally we should "externalize" > cache > > > name somehow, so that it can be changed with no changes to user's code. > > > > > > Alex, > > > Not sure if this is a good idea as you will end up with PARTITIONED > cache > > > without backups with no ability to change that. > > > > > > On Mon, Apr 24, 2017 at 9:35 AM, Alexey Kuznetsov < > akuznet...@apache.org > > > > > > wrote: > > > > > > > Roman, > > > > > > > > Just as idea, how about in case of user does not configured > > "REDIS_CACHE" > > > > then create it via ignite.getOrCreateCache(new > > > > CacheConfiguration("REDIS_CACHE")) > > > > and prin warning to log "REDIS_CACHE not configured, using default > > > > partitioned cache". > > > > > > > > What do you think? > > > > > > > > On Mon, Apr 24, 2017 at 10:26 AM, Roman Shtykh > > <rsht...@yahoo.com.invalid > > > > > > > > wrote: > > > > > > > > > Denis, Igor, > > > > > What can be done now > > > > > 1. create a default cache name for Redis data, e.g. "REDIS_CACHE" > > that > > > > has > > > > > to be configured explicitly in xml file (as it is done with other > > > caches) > > > > > by a user if he/she needs Redis protocol. > > > > > 2. Force users to specify cache names as prefix to their keys, so > > that > > > we > > > > > can parse and switch between caches. > > > > > The 1st one is a very quick fix I can do today. This can be > extended > > in > > > > > future to have a separate cache for each data type. > > > > > Roman > > > > > > > > > > > > > > > On Monday, April 24, 2017 12:15 AM, Denis Magda < > > > dma...@gridgain.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Roman, would you suggest a quick solution for the redis > integration > > or > > > > > even > > > > > implement it in the nearest couple of days? We need to change the > > > defaul > > > > > cache name in 2.0. Otherwise, it can be done only in an year or so > in > > > > 3.0. > > > > > > > > > > Denis > > > > > > > > > > On Sunday, April 23, 2017, Seliverstov Igor <gvvinbl...@gmail.com> > > > > wrote: > > > > > > > > > > > Hi Roman, > > > > > > > > > > > > The ticket number is IGNITE-3488. > > > > > > > > > > > > It's planned not to have null-named or default caches at all. All > > the > > > > > > caches must be defined explicitly or via templates and have > names. > > > The > > > > > > current implementation uses a cache with null name, so, we need > > some > > > > > > configuration property to define which cache to use or mapping in > > > case > > > > of > > > > > > using Redis databases. > > > > > > > > > > > > Regards, > > > > > > Igor > > > > > > > > > > > > 22 апр. 2017 г. 8:47 пользователь "Roman Shtykh" > > > > > <rsht...@yahoo.com.invalid > > > > > > > > > > > > > написал: > > > > > > > > > > > > > Hi Igor, > > > > > > > The current implementation supports only STRING data type of > > Redis. > > > > In > > > > > > > addition, AFAIK, scaling Redis per dataset is normally done via > > > > running > > > > > > > separate instances of Redis for each dataset. Therefore my > choice > > > was > > > > > > > storing to the default cache. It looks fine from Redis' > > > perspective, > > > > > but > > > > > > > probably not from Ignite's.For other data types like HASH or > > SORTED > > > > > SET, > > > > > > I > > > > > > > planned to specify cache name by key and treat value inside as > > > > Ignite's > > > > > > > key-values.# Redis has a notion of 'database' and you can > switch > > > > > between > > > > > > > them, but they can be referred only by the number, and limited > to > > > 16 > > > > > > > databases... Not very useful, IMO. > > > > > > > If you still have the default cache, the current Redis > > integration > > > > > should > > > > > > > work as is (I have to recheck it, what is the JIRA ticket for > the > > > > null > > > > > > > cache issue?) > > > > > > > Do you just want to be sure your changes don't affect the Redis > > > > > > > integration, or do you want to extend it to switch between > > caches? > > > > > > > Roman > > > > > > > > > > > > > > On Friday, April 21, 2017 8:17 PM, Seliverstov Igor < > > > > > > > gvvinbl...@gmail.com <javascript:;>> wrote: > > > > > > > > > > > > > > > > > > > > > Hi Roman, > > > > > > > > > > > > > > As far as I inderstand you're the author of the Redis protocol > > > > > > > implementation. > > > > > > > > > > > > > > Currently I'm working on a task to prohibit null names for > caches > > > and > > > > > > I've > > > > > > > found that current implementation implies using of default (aka > > > null > > > > > > named) > > > > > > > cache as a Redis database. > > > > > > > > > > > > > > So, I need your assistance to implement Redis databases and > > > mappings > > > > > them > > > > > > > to particular caches. > > > > > > > > > > > > > > Is it in your plans to do it in near time? > > > > > > > > > > > > > > If not I'll appriciate your thoughts on how to do it properly) > > > > > > > > > > > > > > Regards, > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Alexey Kuznetsov > > > > > > > > > > > > > > > > > > > >
