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. |
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 <[hidden email]> 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. > |
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 <[hidden email]> 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 <[hidden email]> > 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. > > > |
On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <[hidden email]>
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 <[hidden email] > > > 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 <[hidden email]> > > 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. > > > > > > |
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 <[hidden email]> wrote: > On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <[hidden email]> > 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 < > [hidden email] > > > > > 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 < > [hidden email]> > > > 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. > > > > > > > > > > |
On Thu, Nov 26, 2015 at 12:22 PM, Vladimir Ozerov <[hidden email]>
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 <[hidden email] > > > wrote: > > > On Thu, Nov 26, 2015 at 12:15 PM, Vladimir Ozerov <[hidden email]> > > 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 < > > [hidden email] > > > > > > > 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 < > > [hidden email]> > > > > 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. > > > > > > > > > > > > > > > |
Free forum by Nabble | Edit this page |