Thomas Havlik created IGNITE-11013:
--------------------------------------
Summary: 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
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));
{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)
Locked
