andrewosh / mountable-hypertrie Goto Github PK

View Code? Open in Web Editor NEW

26.0 4.0 9.0 198 KB

A Hypertrie wrapper that supports mounting of other Hypertries

License: MIT License

JavaScript 100.00%

mountable-hypertrie's Introduction

mountable-hypertrie

A Hypertrie wrapper that supports mounting of sub-Hypertries.

Usage

A MountableHypertrie can be mounted within another MountableHypertrie by using the mount command:

const store = corestore(ram)
const trie1 = new MountableHypertrie(store)
const trie2 = new MountableHypertrie(store)

trie2.ready(() => {
  trie1.mount('/a', trie2.key, ...)
})

Assuming trie2 has a value 'hello' at /b/c:

trie1.get('/a/b/c', console.log) // Will return Buffer.from('hello')

A mount can be removed by performing a del on the mountpoint :

trie1.del('/a', err => {
  trie1.get('/a/b/c', console.log) // Will print `null`
})

API

mountable-hypertrie re-exposes the hypertrie API, with the addition of the following methods (and a different constructor):

`const trie = new MountableHypertrie(corestore, key, opts)`

corestore: any object that implements the corestore interface. For now, it's recommanded to use random-access-corestore
key is the hypertrie key
opts can contain any hypertrie options

`trie.mount(path, key, opts, cb)`

path is the mountpoint
key is the key for the MountableHypertrie to be mounted at path

opts can include:

{
  remotePath: '/remote/path', // An optional base path within the mount.
  version: 1                  // An optional checkout version
}

Note: We're still adding support for many hypertrie methods. Here's what's been implemented so far:

License

MIT

mountable-hypertrie's People

Contributors

Stargazers

Watchers

Forkers

noclouds poga frando micahscopes distributedweb rangermauve fsteff dwebprotocol bitwebs

mountable-hypertrie's Issues

block verification for mounted tries?

Wondering how does the verification happen when two different tries that have entirely different keys are mounted into one?

Does the data get re-keyed as per the new mounted path or just returns the original? For example:

trie2.ready(() => {
  trie1.mount('/a', trie2.key, ...)
})

// Assuming trie2 has a value 'hello' at /b/c:
trie1.get('/a/b/c', console.log) // Will return Buffer.from('hello')

Who does the caller perceive this hello as belonging to? trie1 or trie2 ? The underlying feed (the hypercore) can it be validated with trie1 or trie2 ?

Add trie deduping test

We should have a test that makes sure simultaneous writes on a two shared tries (tries that have been deduped) don't lead to inconsistent states.

Hidden nodes are always returned

I'm not quite sure if that is a bug or a feature, but I could really use it to work as expected.

I'm currently trying to implement hidden files in hyperdrive (see hyperdrive #301).
I stumbled upon the problem that mountable-hypertrie also returns entries that are marked as hidden, even if opts.hidden is false.

This could probably be solved by adding a check here.
The alternative would be adding a check in hyperdrive, but that would not be a clean solution.

two new tries use the same key

@andrewosh Are the tries supposed to get the same key?
I was expecting them to have 2 different keys...

  const store1 = new Corestore(ram)

  const masterTrie = new MountableHypertrie(store1)
  const slaveTrie1 = new MountableHypertrie(store1)

  masterTrie.ready(()=>{
    console.log('Master key: ', masterTrie.key.toString('hex')) 
  })
  slaveTrie1.ready(()=>{
    console.log('Slave key: ', slaveTrie1.key.toString('hex'))   // same as master
  })

https://repl.it/@DougAnderson444/HyperTrieKeyTest1

I tried to make them have 2 separate stores, but that didn't work out so well.

Feature request: implement batch

needed here holepunchto/hyperdrive#144
related PR https://github.com/hypercore-protocol/hyperdrive/pull/282/files