Aggregate functions (finally!). #54
Conversation
Also put a little TODO reminder.
|
And that test has just shown how fragile this implementation is. |
No arguments are ever passed to the final function so values was a void pointer causing sqlite3_value_type to fail. This simply stopped trying to collect args. Also changed the order of the function definitions to something that made more sense.
No measurable speed-up but slightly simplifies the implementation.
Attempt to account for big-endianness. Don't call sqlserialize unnecessarily. Try to avoid memory-leaks.
And therefore default the name to the step functions name. README and tests have also been updated.
No performance change but reduces bytes allocated by ~5%.
|
I'm still not enamoured by this but I think I've made all the changes that I can. I'm happy for it to be merged once you've checked it over. |
The only unknown is the users function, any other exceptions are bugs in SQLite.jl and should be fixed not hidden away.
|
This code is wild. The tests we have already look great though. I don't mind merging, but I have to admit that I haven't quite grokked the entirety of what's going on. I might have some more time in the next few days, but it may not be until the weekend or early next week to really dig in some more. |
|
There might be some edge cases I've forgotten about but I've tried pretty hard to break it and it's not blown up in my face yet. |
|
I guess my one thing is I'm always a little bummed if a function has to use a |
|
I know you do which is why I made them as small as possible. In this case though, if they weren't there any exceptions thrown by the user's function would leak memory, which I would consider a far greater sin. I'll keep having a poke about though, see what I can do. |
|
+1! |
This is definitely far from finished but the good news is, it works. The bad news is, the implementation is horrifically vile, basically a huge hack full of
unsafe_copy!s to get round the garbage collector. I'll keep working on it over the next couple of days but I thought I'd let you have a look, see if anything jumps out at you.The basic idea is that an integer and a pointer are stored contiguously in the buffer returned by
sqlite3_aggregate_context. The pointer points to a bytearray (allocated withc_mallocso that the garbage collector doesn't free it when the step function finishes executing) which contains the serialized value returned from the user's step function. The integer just stores the length of this bytearray.As I say, this is just a working prototype, I'll try neating it up over the next couple of days.