You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rationale beihind this: BSON.jl already violates BSON specification by allowing saving arbitrary types.
This follows same ides, as long as user makes sure input data follow BSON specification, it is compliant with the specification, but it also allows to persist data that don't follow BSON specification if it's required.
The text was updated successfully, but these errors were encountered:
An alternative approach, which might scale better, would be to partition large vectors/strings into multi-part objects and even breakup large docs into multi-part files. This would allow other loaders to still load and combine the data as necessary. I'd argue that violating the core BSON spec should be avoided and workarounds should remain backward compatible in some form.
Proposal how to fix #67 .
Based on discussion https://julialang.slack.com/archives/C67TK21LJ/p1596027666030200
Test if data fit to Int32 range and use it, othwerwise use 64bit range. #67 (comment) described where specifically the cast is happening.
Rationale beihind this: BSON.jl already violates BSON specification by allowing saving arbitrary types.
This follows same ides, as long as user makes sure input data follow BSON specification, it is compliant with the specification, but it also allows to persist data that don't follow BSON specification if it's required.
The text was updated successfully, but these errors were encountered: