-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aggregations support #12
Comments
It is in the works and will be added to the client soon. |
Really looking forward to it! |
👍 |
2 similar comments
+1 |
👍 |
+ 1 |
+1 |
4 similar comments
+1 |
+1 |
+1 |
+1 |
Wow, look at the demand! Moved to the top of the priority list. Is anyone blocked on this? |
+1 |
Thanks! Looking forward for this feature |
+1 |
Hi Folks --- Can you tell us what you're using Ruby and Aerospike for? --- just answer here Helping us understand who uses ruby helps us prioritize ruby work (higher) ! Thanks! |
Hi Brian! |
Hello Brian, we have some analytical requirements and having aggregations support is absolute must here. |
Cool, thanks for the info, and I'm having some private discussions too. It sounds like you're mostly using aerospike for key-value and need a few aggregations. Here's the technical problem: we map-reduce on the servers in a parallel fashion, partially reduce on the servers, then do a final reduce stage on the client. Cool, but our map-reduce language is Lua. We need Lua running inside Ruby. Since we did a "native ruby" client (which is great and easier to use for all of you), we need a way to call out to Lua for that final step. Any suggestions of the best way to implement that? |
The most up-to-date and maintained LUA bridge is this gem: https://github.com/jmettraux/rufus-lua Alternatives: I have little experience working with C bindings /FFI Interface, but if you explain the problem in detail, I could spike a proof of concept (maybe with 2 competing approaches, C vs. FFI), what do you think? |
it seems that this issue is stalled.... any new info on this? |
* support multiple results on same bin * add record_bin_multiplicity policy for backwards compatibility The default value Aerospike::RecordBinMultiplicity::SINGLE maintains the client behavior pre-2.2 of returning only a single result value for any record bin; if multiple read operations return values for the same bin, the last result of the last operation is returned. Set OperatePolicy#record_bin_multiplicity to Aerospike::RecordBinMultiplicity::ARRAY to return the results of multiple read operations on the same record in as an array. * avoid duplicate key lookup * fix names for get_by_rank(_range) operations * update docs re. results for multiple read ops on same bin * cleanup/reformat policy docs * document OperatePolicy & RecordBinMultiplicity
Still not implemented? It has been 3 years :( I really need this :( |
any particular reason, why aggregations are not supported??
http://www.aerospike.com/docs/architecture/clients.html
Would love to see it soon in the gem!
The text was updated successfully, but these errors were encountered: