Thanks Pavel.


I guess I’m confused that the type in question is not persisted, it is
ephemeral. Is Ignite persisting knowledge about these types behind the
scenes?



Raymond.



*From:* Pavel Tupitsyn [mailto:ptupit...@apache.org]
*Sent:* Wednesday, May 16, 2018 7:02 PM
*To:* user@ignite.apache.org
*Subject:* Re: Binary type has different fields error



In general, Ignite is tolerant to changes within your types, adding fields,
removing them.

But field type change is a breaking change.



You have to use a new field name.



Other Ignite experts may give advice on how to update schema, I'm a bit out
of the loop on this.



Thanks,

Pavel



On Wed, May 16, 2018 at 7:06 AM, Raymond Wilson <raymond_wil...@trimble.com>
wrote:

I just changed a field in a class from a long to a Guid.



The class in question is marked [Serializable] and is passed to Ignite
compute functions as a part of an argument to the compute function and is
not saved to the persistent store.



When I run the modified code against an Ignite grid with a persistent data
store I get the following error. Is this intentional? How should type
evolution ephemeral constructs handed to compute functions in Ignite be
handled?





Exception: System.AggregateException: One or more errors occurred. --->
Apache.Ignite.Core.Binary.BinaryObjectException: Binary type has different
field types [typeName=VSS.TRex.Filters.CellPassAttributeFilter,
fieldName=ElevationRangeDesignID, fieldTypeName1=long, fieldTypeName2=UUID]
---> Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.binary.BinaryObjectException: Binary type has different
field types [typeName=VSS.TRex.Filters.CellPassAttributeFilter,
fieldName=ElevationRangeDesignID, fieldTypeName1=long, fieldTypeName2=UUID]

                at
org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:1033)

                at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:444)

                at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:186)

                at
org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1303)

                at
org.apache.ignite.internal.processors.platform.PlatformContextImpl.processMetadata(PlatformContextImpl.java:336)

                at
org.apache.ignite.internal.processors.platform.binary.PlatformBinaryProcessor.processInStreamOutLong(PlatformBinaryProcessor.java:70)

                at
org.apache.ignite.internal.processors.platform.PlatformAbstractTarget.processInStreamOutLong(PlatformAbstractTarget.java:87)

                at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)





   at Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.ExceptionCheck()

   at Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.CallLongMethod(GlobalRef
obj, IntPtr methodId, Int64* argsPtr)

   at
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInStreamOutLong(GlobalRef
target, Int32 opType, Int64 memPtr)

   at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutLong(Int32 type,
Action`1 writeAction)

   --- End of inner exception stack trace ---

Etc…..



Thanks,

Raymond.

Reply via email to