My preference would be to deserialize and grab the fields using reflection, assuming the class is available on the server. If the class is not available, then a corresponding field-access operation should produce an exception with a proper error message, instructing user how to address it.
There is no need to punish users with some idealistic unsupported exceptions if the classes are available on the server side. D. On Tue, Dec 8, 2015 at 4:16 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > Alex, > > I was wrong about OptimizedMarshaller. We handle Externalizable a bit > differently: we immediately swtich to "raw mode" and write object's content > in raw form. This situation can be detected using several flags in object > header. But the same flags will be set if user implemented Binarizable and > manually switched object to raw mode. So the answer is no - we cannot > detected this situation reliably at the moment. > > May be some new flag could help us. It could mean "cannot read fields from > deserialized object". > > On Tue, Dec 8, 2015 at 3:03 PM, Alexey Goncharuk < > alexey.goncha...@gmail.com > > wrote: > > > Vova, > > > > We still have the logic that allows us to use reflection to get values in > > indexing, so basically the change is an additional check during the query > > processor start. > > > > My concern regarding (2) is that a server node must have model classes in > > the classpath in order to check that we should deserialize values for > > indexing. If a server node does not have classes in the classpath and > user > > still uses Externalizable classes on client, we will still end up with > the > > same situation and it looks like we will not be able to detect it. Is > there > > a way to tell that an object was externalizable without the class on > server > > node? > > >
