CSV (ORecordDocument2csv) vs Binary (ORecordSerial) in clients

[mindplay.dk]

The documentation doesn't explain why there are two serialization formats - CSV (ORecordDocument2csv) and Binary (ORecordSerial) which can be selected by the Client.

When or why would you use one or the other?

If I had to guess, I would say the binary format used by ORecordSerial is probably the more modern one, and likely results in less encoding overhead on the server, and less decoding overhead on the client?

Other than legacy protocol support (version < 22) is there any practical reason to support both in a client, or is it fine to just support ORecordSerial ?

[GoorMoon]

Like you mentioned above ORecordSerializerBinary is more modern serialization format

The binary schemaless serialization is an attempt to define a serialization format that can serialize a document containing all the information about the structure and the data, with no need of a external schema definition and with support for partial serialization/deserialization.

 

Its depend to how many versions of orientdb your client suppose to support

[Rasmus Schultz]

I have read the documentation - I understand what it is, I need to understand why there are two formats. The documentation explains what they are, not why they exist.

Does the newer binary format supersede or replace the older CSV format? Should the older CSV format be considered obsolete, except for backwards compatibility?

My goal is to support OrientDB 2.0, so I don't need to implement or support the older CSV format?

Thanks, I'm not trying to be pedantic, just trying to make sure I understand the reason why there are two serialization formats - in many cases, having two implementations of something means you have different implementations optimized for different scenarios. Can I assume this is not the case here? The binary format will eventually obsolete the older CSV format?

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/DjI7H5dGAik/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emanuel]

Hi All,

The reason that are there two formats is just an historical reason, the CSV format was the one used in any version 0.* 1.*, for both disc and network, since 2.0 we developed a new binary serialization to improve performance and flexibility, but we guarantee the support of the CSV in 2.0 for both network and disc.

If your target is implement a client for the 2.0, you need just the binary format.

Anyway are you writing an open source client ? is there any link info to reach you?

We have a contributors channel that we use to communicate with the drivers developers and other contributors, where we notify about all the changes to the protocol, if you are interested you can ask for subscription.

Thank you
bye

You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.

[Rasmus Schultz]

Yes, myself and a coworker have started working on a binary client for PHP - although I was just told somebody else is working on the same thing, the guy who wrote the Python client?

Our goal is to have a fairly lightweight client, and we're targeting the 2.0 release as the first supported version for this client, to avoid lugging around any legacy baggage.