-
Notifications
You must be signed in to change notification settings - Fork 58
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
lmdbscan: better ability to handle duplicates in a special way #17
Comments
I think its possible that a straightforward solution to this problem is to have the Scanner.Set and Scanner.SetNext functions actually call Cursor.Get, setting Scanner.Key, Scanner.Val, and Scanner.Err and buffering the result for the next call to Scanner.Scan.
I believe that this can also work for scanning DupFixed databases.
|
Described in #17. The Scanner.Set and Scanner.SetNext methods actually call Cursor.Get to prepare for the next call to Scanner.Scan, which becomes a noop. The return value added to the methods should allow more concise representation of complex scanning behaviors. Most existing code should behave the same. Code will not behave correctly if Scanner.Key, Scanner.Val, or Scanner.Err are accessed following a call to Scanner.Set, expecting to retrieve values from a preceding call to Scanner.Scan.
I think the proposed solution seems pretty good. The |
I think this is orthogonal to a separate method to set |
Scanning over databases and treating values for duplicate keys specially seems to be fairly cumbersome. It is always possible to iterate strictly using Cursor.Next. But a simple action like collecting all values for duplicate keys and printing them, is not as easy is it potentially could be. This is an example of scanning over a database using the NextNoDup and NextDup flags.
It should not be so clumsy. In particular,
scanner.SetNext(nil, nil, lmdb.NextDup, lmdb.NextDup)
is pretty lame.The text was updated successfully, but these errors were encountered: