Closed gsvarovsky closed 3 years ago
This seems quite good to me already. I'll just leave a couple of nitpick-y comments.
How would you handle reading those custom entries? The Quadstore
class already exposes the AbstractLevelDOWN
instance through its .db
property. Is that enough? I think it would make sense to just leave it at that, without further wrapping or methods. There's a nice symmetry in having direct access to leveldb both at the read and batch stages.
How would you handle reading those custom entries?
I agree – just use the db
, or even just read from the AbstractLevelDOWN
you supplied in the first place.
I propose that I try this new interface in m-ld, to see if it solves my problem neatly, before we commit to it. It will mean a bit of a delay. Or are you really keen to get the Beta out?
I propose that I try this new interface in m-ld, to see if it solves my problem neatly, before we commit to it. It will mean a bit of a delay. Or are you really keen to get the Beta out?
I think this is a really nice and useful PR that complements having direct access to the AbstractLevelDOWN
instance, adding to the extendability of quadstore by offering atomic writes of quads + custom data.
I am not in a rush, so it’s really up to you, but I would still like to merge this on its own merit when it’s ready.
@gsvarovsky fantastic work - do you require a beta right away?
Great! Not right away. In the next few days would be great, I have one more optimisation in m-ld to work on before I do another pre-release myself.
All right, feel free to ping me anytime about it. Also, how did you find hacking on quadstore
?
A lot more fun than doing the market research I've been putting off...
It's a great project, you should be proud!
Here is a simple proposal for the key-value interface discussed in #119 .
On the basis that the creator of the quadstore already has access to the raw backend, this proposal does not try to prevent:
write
orclear
.Happy to discuss and add tests/docs when ready.