Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <56FA434B.5050201@gridgain.com>
References: <56FA434B.5050201@gridgain.com>
From: Valentin Kulichenko <valentin.kulichenko@gmail.com>
Date: Tue, 29 Mar 2016 15:49:25 -0700
Message-ID: 
 <CABuYRcqaJ2xHsw0Mz6F9DsmbMR7qbMjOuqTRKhhPBSCegSjHew@mail.gmail.com>
Subject: Re: Controlling type of object inserted in IgniteCache
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a11c151e213761b052f37d92a

--001a11c151e213761b052f37d92a
Content-Type: text/plain; charset=UTF-8

How about adding setTypeNames() configuration property that will be similar
to setTypes(), but for binary objects?

-Val

On Tue, Mar 29, 2016 at 1:56 AM, Denis Magda <dmagda@gridgain.com> wrote:

> Igniters,
>
> In some cases there is necessity to control a type of object that is being
> inserted into a cache.
> Presently this kind of check is accomplished at compile time only relying
> on Java Generics. However it doesn't prevent us from connecting to a
> cluster using a non-generic instance of a cache and put any kind of data in
> it.
> This may be not a harmful intention but rather a silly developer mistake.
>
> I see the following options here.
>
> 1) First CacheInterceptor based approach.
> Specify a unique interceptor per cache setting expected typeName/typeId to
> it at construction time and the interceptor will validate object type in
> onBeforePut() method.
> Disadvantages:
> - cache interceptor have to be created for every cache;
> - cache interceptor class has to be located in servers classpath. It means
> that we won't be able to start a new cache with its interceptor later.
>
> 2)  Second CacheInterceptor based approach.
> A generic cache interceptor can be created. It will be populated with a
> map of cacheName->typeName values at initialization time and validation may
> look like below
>
> @CacheNameResource String cacheName;
>
> public Object onBeforePut(Cache.Entry<String,BinaryObject>
> entry,BinaryObject  newVal) {
>     if (typeId ==null) {
>         synchronized (cachesTypes) {
>             if (typeId ==null) {
>                 String allowedType =cachesTypes.get(cacheName);
>
>                 if (allowedType ==null) {
>                     typeId =0;
>
>                     throw new IgniteException("No type for cache name:"
> +cacheName);
>                 }
>
>                 typeId = Ignition.ignite().binary().typeId(allowedType);
>             }
>         }
>     }
>
>     if (newVal.type().typeId() !=typeId)
>         throw new IgniteException("Invalid object type [validType="
> +typeId +", wrongType=" + newVal.type().typeId());
>
>     return newVal;
> }
>
> However if we want to start a new cache then we won't be able to add a new
> entry to "cacheTypes" map. 3) MutableConfiguration.setTypes(Class<K>
> keyType, Class<V> valueType) based approach According to the spec
>
> Implementations may further perform type checking on mutative cache
> operations * and throw a {@link ClassCastException} if these checks fail.
>
> If we see that value type is BinaryObject (this can be a case if there
> BinaryObject is not going to be deserialized because no real class exists
> for it) then we can take its typeName/typeId and compare it with the same
> parameters at the time instances of BinaryObjects will be put to cache
> using cache.put(). So, every time cache.put()/putAll() are called we can
> check type on client nodes before sending values to servers. In case of
> CacheEntryProcessors servers will double-check an entry type after the
> entry processor does its job. I prefer the latest approach. Any thoughts on
> this? -- Denis
>

--001a11c151e213761b052f37d92a--