Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Structured keys (Array, Object) not supported #280

Open
gh-axel-czarniak opened this issue May 19, 2021 · 5 comments
Open

Structured keys (Array, Object) not supported #280

gh-axel-czarniak opened this issue May 19, 2021 · 5 comments
Labels

Comments

@gh-axel-czarniak
Copy link

gh-axel-czarniak commented May 19, 2021

I was doing some test on my projet using your library, and an exception was thrown for a major type 4 not supported on this payload:

Diagnostic payload: {[3,0,0]:"test"}

But the major type 4 is working with this one: [{0: "0"}, {0: "1"}]

I'm using the default CBORMapper, with the method: readValues(buffer, Object.class) for this test.

Is this a problem on the library ? Or it's not supported ? In the second case, do you plan to support it in the future ?

@cowtowncoder
Copy link
Member

@axelczk Please include some kind of reproduction, and perhaps stack trace / exception message. Is the issue with values or key type? And why are you using readValues() (or should that be readValue())?

@gh-axel-czarniak
Copy link
Author

Here is a payload that fails:

0xA1, 0x83 , 0x03, 0x00, 0x00, 0x64, 0x74, 0x65, 0x73, 0x74 

The problem is: the library doesn't accept array as a fieldName.

The exception is thrown in: _decodeNonStringName(int) :

throw _constructError("Unsupported major type ("+type+") for CBOR Objects, not (yet?) supported, only Strings");

@cowtowncoder
Copy link
Member

Correct: this is not supported and I am not quite sure how it could be -- it would require transformation of some kind from whatever array type is being used into Java String, essentially.
If this was, say, a byte[] equivalent containing UTF-8 encoded name, that'd be easy enough, but without some kind of metadata or configuration it is not safe to assume this in general.

@gh-axel-czarniak
Copy link
Author

gh-axel-czarniak commented Jun 1, 2021

I would say you should deserialize it in the same way as when a value is an array but it's easier said than done.

Thanks you for your answer. It's very appreciated !

@cowtowncoder
Copy link
Member

The problem is not deserialization as these values can be decoded as values. The problem is that of exposing it via token stream; Object keys are exposed as JsonToken.FIELD_NAME for which String accessor (only) exists. Plus some support for int/long keys.
While it'd be possible to expose other types for CBOR backend, the question beyond that is how to make use of that via databind.

So it is all possible, just quite a bit of work and needing to fit with the API approach.

@cowtowncoder cowtowncoder changed the title (cbor) exception for major type 4 not supported on a particular payload (cbor) Structured keys (Array, Object) not supported Jul 2, 2021
@cowtowncoder cowtowncoder changed the title (cbor) Structured keys (Array, Object) not supported Structured keys (Array, Object) not supported Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants