You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2015/11/26 10:04:44 UTC

Binary "type ID" on public API.

Folks,

We have several public methods which operate on "type ID" concept:

   - IgniteBinary.typeId(String typeName)
   - IgniteBinary.metadata(int typeId)
   - BinaryType.typeId()

These methods came from initial GridGain portables implementation where it
is possbile that there is no type metadata so ID is the only way to operate
on the type.

In Ignite we *always* have type metadata. So I think we can safely remove
mentioned methods.

Thoughts?

Vladimir.

Re: Binary "type ID" on public API.

Posted by Dmitriy Setrakyan <ds...@apache.org>.

On Thu, Nov 26, 2015 at 12:22 PM, Vladimir Ozerov <vo...@gridgain.com>
wrote:

> Yes, because I cannot imagine a use case when user will need type ID
> (except of ID mapper). This appears to be implementation detail.
>

I actually would prefer a reverse approach. Instead of removing typeId, I
would keep it and also add the fieldId methods as well to the BinaryType
API. I think it makes sense to provide all the info to users, instead of
hiding it.


>
> On Thu, Nov 26, 2015 at 12:17 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> >
> > > Sure,
> > >
> > >    1. IgniteBinary.typeId(String typeName) -> no replacement, we simply
> > do
> > >    not need it.
> > >    2. IgniteBinary.metadata(int typeId) -> use
> > IgniteBinary.metadata(String
> > >    typeName) instead
> > >    3. BinaryType.typeId() -> use BinaryType.typeName() instead.
> > >
> >
> > Are you proposing to completely remove typeID from the API?
> >
> >
> > >
> > >
> > > On Thu, Nov 26, 2015 at 12:12 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >
> > > wrote:
> > >
> > > > Vladimir,
> > > >
> > > > Can you describe the new APIs to get this information in Ignite?
> > > >
> > > > Thanks,
> > > > D.
> > > >
> > > > On Thu, Nov 26, 2015 at 12:04 PM, Vladimir Ozerov <
> > vozerov@gridgain.com>
> > > > wrote:
> > > >
> > > > > Folks,
> > > > >
> > > > > We have several public methods which operate on "type ID" concept:
> > > > >
> > > > >    - IgniteBinary.typeId(String typeName)
> > > > >    - IgniteBinary.metadata(int typeId)
> > > > >    - BinaryType.typeId()
> > > > >
> > > > > These methods came from initial GridGain portables implementation
> > where
> > > > it
> > > > > is possbile that there is no type metadata so ID is the only way to
> > > > operate
> > > > > on the type.
> > > > >
> > > > > In Ignite we *always* have type metadata. So I think we can safely
> > > remove
> > > > > mentioned methods.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Vladimir.
> > > > >
> > > >
> > >
> >
>

Re: Binary "type ID" on public API.

Posted by Vladimir Ozerov <vo...@gridgain.com>.

Yes, because I cannot imagine a use case when user will need type ID
(except of ID mapper). This appears to be implementation detail.

On Thu, Nov 26, 2015 at 12:17 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > Sure,
> >
> >    1. IgniteBinary.typeId(String typeName) -> no replacement, we simply
> do
> >    not need it.
> >    2. IgniteBinary.metadata(int typeId) -> use
> IgniteBinary.metadata(String
> >    typeName) instead
> >    3. BinaryType.typeId() -> use BinaryType.typeName() instead.
> >
>
> Are you proposing to completely remove typeID from the API?
>
>
> >
> >
> > On Thu, Nov 26, 2015 at 12:12 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >
> > wrote:
> >
> > > Vladimir,
> > >
> > > Can you describe the new APIs to get this information in Ignite?
> > >
> > > Thanks,
> > > D.
> > >
> > > On Thu, Nov 26, 2015 at 12:04 PM, Vladimir Ozerov <
> vozerov@gridgain.com>
> > > wrote:
> > >
> > > > Folks,
> > > >
> > > > We have several public methods which operate on "type ID" concept:
> > > >
> > > >    - IgniteBinary.typeId(String typeName)
> > > >    - IgniteBinary.metadata(int typeId)
> > > >    - BinaryType.typeId()
> > > >
> > > > These methods came from initial GridGain portables implementation
> where
> > > it
> > > > is possbile that there is no type metadata so ID is the only way to
> > > operate
> > > > on the type.
> > > >
> > > > In Ignite we *always* have type metadata. So I think we can safely
> > remove
> > > > mentioned methods.
> > > >
> > > > Thoughts?
> > > >
> > > > Vladimir.
> > > >
> > >
> >
>

Re: Binary "type ID" on public API.

Posted by Dmitriy Setrakyan <ds...@apache.org>.

On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <vo...@gridgain.com>
wrote:

> Sure,
>
>    1. IgniteBinary.typeId(String typeName) -> no replacement, we simply do
>    not need it.
>    2. IgniteBinary.metadata(int typeId) -> use IgniteBinary.metadata(String
>    typeName) instead
>    3. BinaryType.typeId() -> use BinaryType.typeName() instead.
>

Are you proposing to completely remove typeID from the API?


>
>
> On Thu, Nov 26, 2015 at 12:12 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > Vladimir,
> >
> > Can you describe the new APIs to get this information in Ignite?
> >
> > Thanks,
> > D.
> >
> > On Thu, Nov 26, 2015 at 12:04 PM, Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> >
> > > Folks,
> > >
> > > We have several public methods which operate on "type ID" concept:
> > >
> > >    - IgniteBinary.typeId(String typeName)
> > >    - IgniteBinary.metadata(int typeId)
> > >    - BinaryType.typeId()
> > >
> > > These methods came from initial GridGain portables implementation where
> > it
> > > is possbile that there is no type metadata so ID is the only way to
> > operate
> > > on the type.
> > >
> > > In Ignite we *always* have type metadata. So I think we can safely
> remove
> > > mentioned methods.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
>

Re: Binary "type ID" on public API.

Posted by Vladimir Ozerov <vo...@gridgain.com>.

Sure,

   1. IgniteBinary.typeId(String typeName) -> no replacement, we simply do
   not need it.
   2. IgniteBinary.metadata(int typeId) -> use IgniteBinary.metadata(String
   typeName) instead
   3. BinaryType.typeId() -> use BinaryType.typeName() instead.

On Thu, Nov 26, 2015 at 12:12 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> Vladimir,
>
> Can you describe the new APIs to get this information in Ignite?
>
> Thanks,
> D.
>
> On Thu, Nov 26, 2015 at 12:04 PM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > Folks,
> >
> > We have several public methods which operate on "type ID" concept:
> >
> >    - IgniteBinary.typeId(String typeName)
> >    - IgniteBinary.metadata(int typeId)
> >    - BinaryType.typeId()
> >
> > These methods came from initial GridGain portables implementation where
> it
> > is possbile that there is no type metadata so ID is the only way to
> operate
> > on the type.
> >
> > In Ignite we *always* have type metadata. So I think we can safely remove
> > mentioned methods.
> >
> > Thoughts?
> >
> > Vladimir.
> >
>

Re: Binary "type ID" on public API.

Posted by Dmitriy Setrakyan <ds...@apache.org>.

Vladimir,

Can you describe the new APIs to get this information in Ignite?

Thanks,
D.

On Thu, Nov 26, 2015 at 12:04 PM, Vladimir Ozerov <vo...@gridgain.com>
wrote:

> Folks,
>
> We have several public methods which operate on "type ID" concept:
>
>    - IgniteBinary.typeId(String typeName)
>    - IgniteBinary.metadata(int typeId)
>    - BinaryType.typeId()
>
> These methods came from initial GridGain portables implementation where it
> is possbile that there is no type metadata so ID is the only way to operate
> on the type.
>
> In Ignite we *always* have type metadata. So I think we can safely remove
> mentioned methods.
>
> Thoughts?
>
> Vladimir.
>