-
Notifications
You must be signed in to change notification settings - Fork 43
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
RFC: enhance (de)serializers options description #976
Comments
We discussed this issue with @Onvember. To sum up: it seems the main problem with this list of options is lack of proper descriptions rather then describing them all in context of Example: However the option is not about this: it just shows on
As we see, it worth to describe it more then just 'load metatables'. Even the description above it not enough, I think: we should give proper examples, which will show how a behaviour changes depending on an option (maybe in different cases). The same is applicable for other options. Please, ask for more information is something is not clear, look over tests in tarantool and experimenting youself to understand the behaviour. We also discussed it with @lenkis and she propose to move (de)serializer options description to its own section. I think it is less important then good descriptions itself (despite I proposed this above), but is also good change. It looks appropriate to move this list into its own section of app server guide. |
We have three public (de)serializer modules: msgpack, json and yaml. Also I guess we'll make msgpackffi module public as possibly more performant alternative to msgpack module when we'll make its behave it exactly as msgpack (see tarantool/tarantool#4499).
All three (four) modules have different applicable settings (see also tarantool/tarantool#4622) and it would be simpler to understand them if they would be described for each module separately. Now it is described once on json module page and linked from msgpack and yaml pages.
Maybe there other ways to organize the information about all those options. I'll don't mind against any other way that will give enough information for a user.
The table of supported options (gathered from 2.3.0-206-ge68665503 source code):
(1) YAML supports references, so cycles can be encoded and there are much less reason to support a depth boundary.
(2) MsgPack encodes 32/64 bit floating point values w/o a precision loss; JSON and YAML support this option, because they are text formats and format numbers in human-readable way.
(3) Don't know a reason.
Empty cells in msgpackffi column is the subject to support in the scope of tarantool/tarantool#4499
The text was updated successfully, but these errors were encountered: