@lxsameer does this make sense?
Hi! I am trying to get started using ormap sample (http://replikativ.io/tut/get-started.html) and cannot understand the streaming behavior. E.g. if I do
assoc :name "Peter" then I see my "streamed-to" atom updated. Then I do dissoc :name and see it empty. But if I do assoc :name "Peter" again - it is still empty. Changing name to another value works though, e.g. assoc :name "Sam" will change the name. Does every transaction have to have a "unique" value?
Do you mean you have used calls like:
(<?? S (ors/assoc! stage-b [user ormap-id] :name [['assoc [:name "Peter"]]]))?
This is a bit clumsy, I know.
The point is that decouple the associativity from the semantics of the operations, but in hindsight we should have just skipped the nested assoc.
Please open an issue. We are not doing much work on replikativ itself at the moment, but plan to lift its features into datalog land to make it easier :).
I have given a talk about our integrated datalog stack at https://www.youtube.com/watch?v=A2CZwOHOb6U
That was a really interesting talk. I've been tinkering with the datopia abci-host example project a bit (https://github.com/datopia/abci-host/tree/master/example). I'm curious how you expect people to format keys in their applications.
The docs describe using keywords like
:a but I'd expect that in order to be useful, the keys should combine some sort of namespace with some sort of identifier. Would it be possible to use something like :org.mynamepace.app/uuid as a key?
The underlying store is fine with strings containing leading digits, but the transaction validation code in the example application is contrived to reject non-keyword keys.
But in general about expectations - it's a toy application - I'm not expecting people to build on it, necessarily - it only serves as a demonstration of the underlying library.
I should probably spend a day factoring the data structure out of https://github.com/nervous-systems/sputter into an artifact that offers the same functionality - a disk-persistent merkle trie w/ a k/v interface - but without the Ethereum-specific RLP encoding overhead, and a runtime-configurable key decomposition scheme.
with the ability to represent sequences. It's necessary for an EVM implementation (because the hash of the RLP encoding is part of the proof protocol, etc.), but the data structure would be more generally useful without it.
it's transparent to the user, but it's still overhead.
Could you use something like fressian directly?
these are trivial changes
again, a very good read
tries are in general not balanced
are there use cases where they are particularly useful, e.g. in the EVM
?
i mean fulltext search
well, forget about it. i have no idea, i need to think about it more
i'm not actually sure that it's an ideal datastructure for the EVM, as the advantages emerge when there's a high degree of shared structure in the keyspace (e.g. namespace prefixes, per the above example) - the ability to perform prefix searches, etc. - but Ethereum's keys are cryptographic hashes - so it's an unusual choice, because they have no structure to speak of
but a merkle trie is an interesting data structure, just not for their use case ;)
in case somebody missed it, we now have datahike in better shape and aim to incorporate replikativ's replication work into it. https://github.com/replikativ/datahike