[
https://issues.apache.org/jira/browse/IGNITE-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750227#comment-16750227
]
Thomas Havlik commented on IGNITE-11013:
----------------------------------------
I get that the template is supposed to provide a mapping from the complex type
to a JS object, but consider the following, which creates the members as you
define them (which is probably what the user wants anyway):
const nest = new ComplexObjectType().setFieldType("foo",
ObjectType.PRIMITIVE_TYPE.DOUBLE);
const ty = new ComplexObjectType().setFieldType("nest", nest);
Or a schema constructor, where the values of the keys actually do something:
const ty = new ComplexObjectType({
nest: {
foo:ObjectType.PRIMITIVE_TYPE.DOUBLE
}
});
What are your thoughts on this?
Thanks for the quick reply :)
> 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)
