ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: CacheEntry serialization failure
Date Sun, 20 Dec 2015 18:08:56 GMT
May be we can use normal field names by default and add some prefix/suffix
if conflict is found? E.g.:

class A {
    int a; // Write as "a";
}

class B extends A {
    int a; // Write as "B_a";
}

On Fri, Dec 18, 2015 at 10:34 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Folks,
>
> It seems to me that issue here is not with 3rd-party libraries. We just
> don't properly support class hierarchy in binary format. Any class that
> extends another class and has the field with the same name as parent has
> will fail unless user provides custom serialization logic that will handle
> it.
>
> What if we prepend the field name with the simple class name in this case?
> Say, we have two classes:
>
> class A {
>   private int id;
> }
>
> class B extends A {
>   private int id;
> }
>
> In this case we will get two fields: "A.id" and "B.id". The only issue is
> that if there are no name conflict, we should be able to resolve by both
> names - with or without prepended type name. I.e., if A is serialized, you
> can get the field value by "id" or "A.id". This is similar to how it works
> if you join two SQL tables with the same column names.
>
> Any thoughts on whether it's doable or not?
>
> -Val
>
> On Fri, Dec 18, 2015 at 10:05 AM, Andrey Kornev <andrewkornev@hotmail.com>
> wrote:
>
> > In this particular case, the class that fails is a non-static inner class
> > that extends another non-static inner class, so they both end up having
> the
> > compiler-generated "this$0" field.
> >
> > Regards
> > Andrey
> >
> > > Date: Fri, 18 Dec 2015 20:44:12 +0300
> > > Subject: Re: CacheEntry serialization failure
> > > From: vozerov@gridgain.com
> > > To: dev@ignite.apache.org
> > >
> > > The most straightforward solution which comes to my mind - *do not ever
> > use
> > > BinaryMarshaller by default*. Always fallback to OptimizedMarshaller
> > unless
> > > user explicitly asked us to use binary format (e.g. through package
> > > wildcards).
> > >
> > > BTW, we already do this for Externalizable and readObject/writeObject.
> > >
> > > On Fri, Dec 18, 2015 at 8:41 PM, Vladimir Ozerov <vozerov@gridgain.com
> >
> > > wrote:
> > >
> > > > Ah, I saw your problem with DirectedSpecifics. We need to think about
> > how
> > > > to solve it. Here is the case:
> > > > 1) Class is Serilzable and cannot be changed;
> > > > 2) There are several duplicated field names;
> > > > => BinaryMarshaller cannot handle it.
> > > >
> > > > Any thoughts?
> > > >
> > > > On Fri, Dec 18, 2015 at 8:34 PM, Vladimir Ozerov <
> vozerov@gridgain.com
> > >
> > > > wrote:
> > > >
> > > >> I fixed the problem, it was a bug actually.
> > > >>
> > > >> By default classes which has some custom Java logic (e.g.
> > Externalizable,
> > > >> or with writeObject/readObject methods) will be written using
> > > >> OptimizedMarshaller, so similar field names is not a problem.
> > > >> If you want to serialize such class in binary format and have
> > duplicate
> > > >> field names, you should provide your own BinarySerializer, which
> will
> > write
> > > >> these fields with different names.
> > > >>
> > > >> On Fri, Dec 18, 2015 at 8:07 PM, Andrey Kornev <
> > andrewkornev@hotmail.com>
> > > >> wrote:
> > > >>
> > > >>> How am I supposed to handle this situation if the class comes
from
> a
> > 3d
> > > >>> party I can't modify?
> > > >>>
> > > >>> Thanks
> > > >>> Andrey
> > > >>>
> > > >>> > Date: Fri, 18 Dec 2015 09:12:22 +0300
> > > >>> > Subject: Re: CacheEntry serialization failure
> > > >>> > From: vozerov@gridgain.com
> > > >>> > To: dev@ignite.apache.org
> > > >>> >
> > > >>> > I'll take a look.
> > > >>> >
> > > >>> > On Fri, Dec 18, 2015 at 4:37 AM, Valentin Kulichenko <
> > > >>> > valentin.kulichenko@gmail.com> wrote:
> > > >>> >
> > > >>> > > Folks,
> > > >>> > >
> > > >>> > > It looks like CacheEntry implementation (i.e., the entry
that
> > > >>> contains
> > > >>> > > version) can't be properly serialized with the
> BinaryMarshaller.
> > I
> > > >>> created
> > > >>> > > the test and the ticket:
> > > >>> https://issues.apache.org/jira/browse/IGNITE-2203
> > > >>> > >
> > > >>> > > Can someone take a look?
> > > >>> > >
> > > >>> > > -Val
> > > >>> > >
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message