ss1
Forum Replies Created
-
> The serialization format does not contain any information about whether or not strings (symbols) are interned, or atomic. It contains a tag (number) followed by some data.
It provides details that the data is a symbol, hence to kdb+ its treated as such rather than a vector of characters.
How other systems choose to store data is dependant on whatever way the other system intends to be architected & cant be answered on what recommendation all 3rd party systems should do (should they intend to store data rather than letting kdb+ store it).
-
kdb+ on-disk format is not documented and subject to change. kdb+ should be used to read/write its data.
A shared object for kdb+ can be written, if a 3rd party needs access to data (e.g. q script reads data from disk & calls c function with data, or vice-versa) , https://code.kx.com/q/interfaces/using-c-functions/ , or kdb+ can use IPC to send the data to/from a 3rd party.
code.kx.com
Interfaces | kdb+ and q documentation - kdb+ and q documentation
KX interfaces between kdb+ and other languages and services
-
Consider the type output on a list of longs, list of chars (string) , symbol, etc
q)type 1 2 3 7h q)type "abcde" 10h q)type `abcde -11h q)type "a" -10h q)type 1 -7h q)type `abc`def 11h
It shows positive values for 7h (vector of long), 10h (vector of char). It shows a atom type for the symbol (changing to 11h when vector of symbols). There is no ‘string’ type, but often referred to when talking about type 10h (as seen above).
This may be of some relevance Strings
Symbols are interned. Imagine sending a symbol to another process (when IPC is used). It may never have seen that symbol before, it needs to know what the symbol represents so it may also intern it. So in your particular example of IPC representation it may appear similar (to tell the other process what it represents and that it should intern it as a symbol).
code.kx.com
Data types | Basics | kdb+ and q documentation - kdb+ and q documentation
Every kdb+ object has a data type. This page tabulates the datatypes.
-
What is your use-case for needing to serialise to disk? what is intended to read this data & must it be kdb serialised format? I assume the serialisation currently used by this process is to send/receive data over IPC?
-
You should find it in the readme file provided with the release.
The web link provided has the following at the top of the page “The README.txt of the current 4.1 release contains a full list of changes. Some of the highlights are listed below.”
Thanks
-
error appears to be couldn’t find javakdb 1.0 on the system
download javakdb version 1.0 from here https://github.com/KxSystems/javakdb/releases/tag/1.0 & run a `mvn compile install` to install that package, prior to building JDBC -
Yes they are completely different. That was the reasoning behind the queries of why/what it was being used for & what is trying to replicated from the original use-case which Im not clear of. Was it some reverse engineering of the on-disk format, or was it something like an in-house use for recording ipc messages, etc.
-
The C api has b9/d9 to serialise/deserialise (e.g. https://code.kx.com/q/interfaces/capiref/#b9-serialize ) if you wish to turn a turn anything to bytes (as would be bytes it can be read/write disk in a normal manner if needed). If that helps in someway. Im not clear on the use case to know what its required for, or how the application used whatever serialised data it or something else generated.
code.kx.com
C API reference | Interfaces | kdb+ and q documentation - kdb+ and q documentation
A reference guide to the API for connecting a C program to a kdb+ server process