Denis,
Yes, as we do not know which field to pick, we return null.
On Mon, Dec 21, 2015 at 12:00 PM, Denis Magda <[email protected]> wrote:
> Sounds good for me. I would go for this approach.
>
> In addition if to consider your example below and the user decides to look
> up a field by its simple name then he/she will get nothing or exception
> (depending on the API), correct?
> As an example for this case the method will return null
>
> BinaryObject obj = ...;
> Object val = obj.field("x"); // null will be returned cause we don't know
> what particular 'x' we have to return
>
>
> --
> Denis
>
> On 12/21/2015 11:48 AM, Vladimir Ozerov wrote:
>
>> Folks,
>>
>> I thought about the solution a bit more and came to the following design.
>>
>> *Scenario:*
>> class A {
>> int x;
>> }
>> class B : extends A {
>> int y;
>> }
>>
>> *Solution:*
>> 1) Field A.x is written as *"A.x"*, field B.x is written as *"B.x"*. I.e.
>> *both
>> conflicting fields are prefixed* with simple name of the owning class.
>> 2) API is unchanged. User manipulates these fields on all public methods
>> in
>> exactly the same way: "A.x" and "B.x".
>>
>> *Rationale:*
>> 1) We cannot prefix only some of conflicting fields. E.g. if decide to
>> prefix only A.x, then it is not clear how to handle this case:
>>
>> class B extends A implements Binarylizable {
>> void write(BinaryWriter writer) {
>> writer.writeInt("B.x", x); // User intentionally written field as
>> "B.x".
>> }
>> }
>>
>> BinaryObject obj = ...;
>> Object val = obj.field("B.x"); // Should we lookup for "B.x" as user asked
>> us, or just for "x"?
>>
>> Prefixing all conflicting fields with class name resolves the problem.
>>
>> 2) If we add methods to manipulate fields not only by name, but by
>> (typeName + fieldName) as well, then we will have to add *9 new methods*
>> to
>>
>> API:
>> BinaryType.fieldTypeName(String typeName, String fieldName);
>> BinaryType.field(String typeName, String fieldName);
>> BinaryObject.field(String typeName, String fieldName);
>> BinaryObject.hasField(String typeName, String fieldName);
>> BinaryObjectBuilder.getField(String typeName, String fieldName);
>> BinaryObjectBuilder.setField(String typeName, String fieldName, ...); // 3
>> overloads
>> BinaryObjectBuilder.removeField(String typeName, String fieldName);
>>
>> This is definitely an overkill for such a rare scenario.
>>
>> Thoughts?
>>
>> On Mon, Dec 21, 2015 at 11:22 AM, Vladimir Ozerov <[email protected]>
>> wrote:
>>
>> Agree, prefixing parent class fields sound like a better option.
>>> Regarding aliases - I need some time to understand internal mechanics.
>>> Will answer this a bit later.
>>>
>>> On Mon, Dec 21, 2015 at 11:18 AM, Dmitriy Setrakyan <
>>> [email protected]
>>>
>>>> wrote:
>>>> Vova,
>>>>
>>>> Shouldn’t it be the other way around? Class B writes the field as “a”,
>>>> and
>>>> class A writes it with a prefix (possibly the hash code of the class
>>>> name).
>>>>
>>>> Also, we should clearly document how the SQL queries are affected by
>>>> this.
>>>> AFAIK, we should be using field aliases here, no?
>>>>
>>>> D.
>>>>
>>>> On Sun, Dec 20, 2015 at 10:08 AM, Vladimir Ozerov <[email protected]
>>>> >
>>>> wrote:
>>>>
>>>> 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 <
>>>>> [email protected]> 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 <
>>>>>>
>>>>> [email protected]>
>>>>>
>>>>>> 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: [email protected]
>>>>>>>> To: [email protected]
>>>>>>>>
>>>>>>>> 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 <
>>>>>>>>
>>>>>>> [email protected]
>>>>>
>>>>>> 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 <
>>>>>>>>>
>>>>>>>> [email protected]
>>>>>>
>>>>>>> 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 <
>>>>>>>>>>
>>>>>>>>> [email protected]>
>>>>>>>
>>>>>>>> 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: [email protected]
>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>
>>>>>>>>>>>> I'll take a look.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 18, 2015 at 4:37 AM, Valentin Kulichenko <
>>>>>>>>>>>> [email protected]> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>
>
