⛔️ DEPRECATED: This module has been merged into by the ipfs-interfaces module
Implementation of the datastore interface in JavaScript
- Backed Implementations
- Memory:
src/memory
- level:
datastore-level
(supports any levelup compatible backend) - File System:
datstore-fs
- Memory:
- Wrapper Implementations
- Mount:
datastore-core/src/mount
- Keytransform:
datstore-core/src/keytransform
- Sharding:
datastore-core/src/sharding
- Tiered:
datstore-core/src/tiered
- Namespace:
datastore-core/src/namespace
- Mount:
If you want the same functionality as go-ds-flatfs, use sharding with fs.
const FsStore = require('datastore-fs')
const ShardingStore = require('datastore-core').ShardingDatastore
const NextToLast = require('datastore-core').shard.NextToLast
const fs = new FsStore('path/to/store')
// flatfs now works like go-flatfs
const flatfs = await ShardingStore.createOrOpen(fs, new NextToLast(2))
An adapter is made available to make implementing your own datastore easier:
const { Adapter } = require('interface-datastore')
class MyDatastore extends Adapter {
constructor () {
super()
}
async put (key, val) {
// your implementation here
}
async get (key) {
// your implementation here
}
// etc...
}
See the MemoryDatastore for an example of how it is used.
$ npm install interface-datastore
const MemoryStore = require('interface-datastore').MemoryDatastore
const MountStore = require('datastore-core').MountDatastore
const Key = require('interface-datastore').Key
const store = new MountStore({ prefix: new Key('/a'), datastore: new MemoryStore() })
Available under src/tests.js
describe('mystore', () => {
require('interface-datastore/src/tests')({
async setup () {
return instanceOfMyStore
},
async teardown () {
// cleanup resources
}
})
})
Most API methods accept an AbortSignal as part of an options object. Implementations may listen for an abort
event emitted by this object, or test the signal.aborted
property. When received implementations should tear down any long-lived requests or resources created.
The streaming (put|get|delete)Many
methods are intended to be used with modules such as it-parallel-batch to allow calling code to control levels of parallelisation. The batching method ensures results are returned in the correct order, but interface implementations should be thread safe.
const batch = require('it-parallel-batch')
const source = [{
key: ..,
value: ..
}]
// put values into the datastore concurrently, max 10 at a time
for await (const { key, data } of batch(store.putMany(source), 10)) {
console.info(`Put ${key}`)
}
To allow a better abstraction on how to address values, there is a Key
class which is used as identifier. It's easy to create a key from a Uint8Array
or a string
.
const a = new Key('a')
const b = new Key(new Uint8Array([0, 1, 2, 3]))
The key scheme is inspired by file systems and Google App Engine key model. Keys are meant to be unique across a system. They are typically hierarchical, incorporating more and more specific namespaces. Thus keys can be deemed 'children' or 'ancestors' of other keys:
new Key('/Comedy')
new Key('/Comedy/MontyPython')
Also, every namespace can be parameterized to embed relevant object information. For example, the Key name
(most specific namespace) could include the object type:
new Key('/Comedy/MontyPython/Actor:JohnCleese')
new Key('/Comedy/MontyPython/Sketch:CheeseShop')
new Key('/Comedy/MontyPython/Sketch:CheeseShop/Character:Mousebender')
https://ipfs.github.io/interface-datastore/
PRs accepted.
Small note: If editing the Readme, please conform to the standard-readme specification.
MIT 2017 © IPFS