FoundationDB

Rust Client API 0.2.0

bindings

(Benjamin Fry) #1

This is a cross-post from the Rust Users forum:

The highlights are the integration with the bindingstester and benchmark test suites, as well as native bindings for Tuple to native Rust tuples.

Feedback is of course welcome, Thanks!


(Amirouche) #2

Do you use rust bytekey or do you use the same lexicographic encoding than Python? Actually, I am not sure if encodings are interoperable across bindings.


(Benjamin Fry) #3

Sorry for the late reply. The formats for the packed keys should be compatible across implementations. We did notice that Python appears to convert strings to byte fields rather than storing as strings in the packed key. We weren’t clear about why that was.

This Rust impl should properly encode everything in a portable manner. It would be a bug if not.


(A.J. Beamon) #4

The types supported in the Tuple layer include both byte strings and Unicode strings. The Python 2 string type (str) stores raw byte strings and so is packed as byte strings in the Tuple layer. To get Unicode strings you would need to use the unicode type (e.g. by using u'foo' for string literals).

In Python 3 the situation is reversed, as the str type now represents Unicode strings and you need to use the bytes type for byte strings (e.g. b'foo' for byte literals).


(Amirouche) #5

There is bug in the tracker to replace all 'strings' with b'bytes' but I did not come up with motivation to do it.

Also, I am investigating how to add a layer in my database zehefyu93 to be able to use both wiredtiger and foundationdb. Actually, to be able to replace one with the other. An abstraction, already!

It’s unlikely that I will pick up the work on asyncio bindings. I tried to add some comments!


(A.J. Beamon) #6

To be clear, I think the issue that @amirouche is referring to is that the documentation and examples are written assuming Python 2 syntax in some places. Using b'bytes' works in both versions and so would be preferable. See https://github.com/apple/foundationdb/issues/329.


(Amirouche) #7

Sorry for not being clear.