[
https://issues.apache.org/jira/browse/IGNITE-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750415#comment-16750415
]
Alexey Kosenchuk commented on IGNITE-11013:
-------------------------------------------
Have you seen the BinaryObject class?
You can create it's instance initially empty, or from a template object, or
receive from a cache. And after that you can add new fields using the
setField() method. As well as make other operations with the fields.
It's an alternative (in fact, default) way to operate with Ignite Complex
Objects. W/o direct serialization/deserialization from/to JS objects (where
ComplexObjectType is needed).
It seems BinaryObject corresponds to your idea ;)
Or not?
> Node.js apache-ignite-client ComplexObjectType does not deserialize nested
> objects when the nested type is specified as a ComplexObjectType
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-11013
> URL: https://issues.apache.org/jira/browse/IGNITE-11013
> Project: Ignite
> Issue Type: Bug
> Components: thin client
> Environment: Debian 9, stretch
> "apache-ignite-client": "^1.0.0"
> Reporter: Thomas Havlik
> Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I am trying to navigate the Node.js client and discovered this oddity. I'm
> not sure what the design goal of the type system in the JS client is - is the
> goal to define some sort of default object, or is to define a schema? The
> object does not serve as a default object in my tests, so I'm wondering why
> I'm supposed to feed in actual _values_ and not a schema, like with Mongoose.
> Nested complex types are also not consistently deserialized:
>
> {code:java}
> // Desired behavior: specify nested ComplexObjectType directly as a member,
> get deserialized nested object back
> const nest = new ComplexObjectType({ num: 0 });
> const ty = new ComplexObjectType({ foo: "", nest });
> // Uncommenting the following line results in the expected value being
> returned:
> // ty.setFieldType("nest", nest);
> const cache = (await igniteClient.getOrCreateCache("myCache"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ty);
> await cache.put(1, {
> foo: "bar",
> nest: { num: 1 }
> });
> // Expected output:
> // { foo: "bar",
> // nest: {
> // num: 1 } }
> //
> // Actual output:
> // { foo: "bar",
> // nest: BinaryObject }
> console.dir(await cache.get(1));
> // Additionally, not defining 'nest' in the ComplexObjectType and defining it
> later will throw:
> const nest = new ComplexObjectType({ num: 0 });
> const ty = new ComplexObjectType({ foo: "" });
> ty.setFieldType("nest", nest); // -> IgniteClientError: Field "nest" is
> absent in the complex object type
> {code}
>
> Honestly, working with the JS library without types is hugely painful, even
> with the JS doc. If I am encouraged, I would happily move the Node.js client
> over to Typescript.
>
> Tom
>
> p.s. This is my first issue on JIRA. If it's not filed in the correct place
> or doesn't take the right format - sorry :)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
