Bulk Get
qpfiffer opened this issue · comments
Needs to happen. Round-tripping to get a bunch of keys is terrible.
I can do it if you don't want to bother with go.
@Hamcha Doesn't matter to me, I'll probably knock it out by this weekend. It'll be a good way to test larger transactions.
Spitablling:
POSTing newline delimited keys to the /<database>/_bulk_unjar endpoint should result in a series of alternating size_t (unsigned 32-bit integer) and unsigned char * streams. The first size_t is the size of the stream following.
The rationale for the return type is that I want to preserve the whole keyset. I figure newline delimited keys in the POST data is fine because why would you put newlines in your keys? I'll think on it some more or change it if I find something dumb later.
I agree, if you put \ns in your keys the front end would have tons of other issues anyway. Sadly, size_t is architecture-dependent, we need to use a fixed size.. How about int 64 (since x64 is the main target and you'd have to send what Google has in its data centers several times to overflow it)
-----Original Message-----
From: "Quinlan P." notifications@github.com
Sent: 30/01/2015 06:01
To: "infoforcefeed/OlegDB" OlegDB@noreply.github.com
Cc: "ahcmaH" zikyky@gmail.com
Subject: Re: [OlegDB] Bulk Get (#148)
Spitablling:
POSTing newline delimited keys to the //_bulk_get endpoint should result in a series of alternating size_t (unsigned 32-bit integer) and unsigned char * streams. The first size_t is the size of the stream following.
The rationale for the return type is that I want to preserve the whole keyset. I figure newline delimited keys in the POST data is fine because why would you put newlines in your keys? I'll think on it some more or change it if I find something dumb later.
—
Reply to this email directly or view it on GitHub.=
@Hamcha Definitely, I was thinking a uint64_t would do just fine.
This is done until someone tries to use it for binary data.