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 <dsetrak...@apache.org> wrote: > On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <voze...@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 < > dsetrak...@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 < > voze...@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. > > > > > > > > > >
