Giter Site home page Giter Site logo

level-ttl's Introduction

level

Universal abstract-level database for Node.js and browsers. This is a convenience package that exports classic-level in Node.js and browser-level in browsers, making it an ideal entry point to start creating lexicographically sorted key-value databases.

πŸ“Œ Which module should I use? What is abstract-level? Head over to the FAQ.

level badge npm Node version Test Coverage Standard Common Changelog Community Donate

Table of Contents

Click to expand

Usage

If you are upgrading: please see UPGRADING.md.

const { Level } = require('level')

// Create a database
const db = new Level('example', { valueEncoding: 'json' })

// Add an entry with key 'a' and value 1
await db.put('a', 1)

// Add multiple entries
await db.batch([{ type: 'put', key: 'b', value: 2 }])

// Get value of key 'a': 1
const value = await db.get('a')

// Iterate entries with keys that are greater than 'a'
for await (const [key, value] of db.iterator({ gt: 'a' })) {
  console.log(value) // 2
}

All asynchronous methods also support callbacks.

Callback example
db.put('a', { x: 123 }, function (err) {
  if (err) throw err

  db.get('a', function (err, value) {
    console.log(value) // { x: 123 }
  })
})

TypeScript type declarations are included and cover the methods that are common between classic-level and browser-level. Usage from TypeScript requires generic type parameters.

TypeScript example
// Specify types of keys and values (any, in the case of json).
// The generic type parameters default to Level<string, string>.
const db = new Level<string, any>('./db', { valueEncoding: 'json' })

// All relevant methods then use those types
await db.put('a', { x: 123 })

// Specify different types when overriding encoding per operation
await db.get<string, string>('a', { valueEncoding: 'utf8' })

// Though in some cases TypeScript can infer them
await db.get('a', { valueEncoding: db.valueEncoding('utf8') })

// It works the same for sublevels
const abc = db.sublevel('abc')
const xyz = db.sublevel<string, any>('xyz', { valueEncoding: 'json' })

Install

With npm do:

npm install level

For use in browsers, this package is best used with browserify, webpack, rollup or similar bundlers. For a quick start, visit browserify-starter or webpack-starter.

Supported Platforms

At the time of writing, level works in Node.js 12+ and Electron 5+ on Linux, Mac OS, Windows and FreeBSD, including any future Node.js and Electron release thanks to Node-API, including ARM platforms like Raspberry Pi and Android, as well as in Chrome, Firefox, Edge, Safari, iOS Safari and Chrome for Android. For details, see Supported Platforms of classic-level and Browser Support of browser-level.

Binary keys and values are supported across the board.

API

The API of level follows that of abstract-level. The documentation below covers it all except for Encodings, Events and Errors which are exclusively documented in abstract-level. For options and additional methods specific to classic-level and browser-level, please see their respective READMEs.

An abstract-level and thus level database is at its core a key-value database. A key-value pair is referred to as an entry here and typically returned as an array, comparable to Object.entries().

db = new Level(location[, options])

Create a new database or open an existing database. The location argument must be a directory path (relative or absolute) where LevelDB will store its files, or in browsers, the name of the IDBDatabase to be opened.

The optional options object may contain:

  • keyEncoding (string or object, default 'utf8'): encoding to use for keys
  • valueEncoding (string or object, default 'utf8'): encoding to use for values.

See Encodings for a full description of these options. Other options (except passive) are forwarded to db.open() which is automatically called in a next tick after the constructor returns. Any read & write operations are queued internally until the database has finished opening. If opening fails, those queued operations will yield errors.

db.status

Read-only getter that returns a string reflecting the current state of the database:

  • 'opening' - waiting for the database to be opened
  • 'open' - successfully opened the database
  • 'closing' - waiting for the database to be closed
  • 'closed' - successfully closed the database.

db.open([callback])

Open the database. The callback function will be called with no arguments when successfully opened, or with a single error argument if opening failed. If no callback is provided, a promise is returned. Options passed to open() take precedence over options passed to the database constructor. The createIfMissing and errorIfExists options are not supported by browser-level.

The optional options object may contain:

  • createIfMissing (boolean, default: true): If true, create an empty database if one doesn't already exist. If false and the database doesn't exist, opening will fail.
  • errorIfExists (boolean, default: false): If true and the database already exists, opening will fail.
  • passive (boolean, default: false): Wait for, but do not initiate, opening of the database.

It's generally not necessary to call open() because it's automatically called by the database constructor. It may however be useful to capture an error from failure to open, that would otherwise not surface until another method like db.get() is called. It's also possible to reopen the database after it has been closed with close(). Once open() has then been called, any read & write operations will again be queued internally until opening has finished.

The open() and close() methods are idempotent. If the database is already open, the callback will be called in a next tick. If opening is already in progress, the callback will be called when that has finished. If closing is in progress, the database will be reopened once closing has finished. Likewise, if close() is called after open(), the database will be closed once opening has finished and the prior open() call will receive an error.

db.close([callback])

Close the database. The callback function will be called with no arguments if closing succeeded or with a single error argument if closing failed. If no callback is provided, a promise is returned.

A database may have associated resources like file handles and locks. When the database is no longer needed (for the remainder of a program) it's recommended to call db.close() to free up resources.

After db.close() has been called, no further read & write operations are allowed unless and until db.open() is called again. For example, db.get(key) will yield an error with code LEVEL_DATABASE_NOT_OPEN. Any unclosed iterators or chained batches will be closed by db.close() and can then no longer be used even when db.open() is called again.

db.supports

A manifest describing the features supported by this database. Might be used like so:

if (!db.supports.permanence) {
  throw new Error('Persistent storage is required')
}

db.get(key[, options][, callback])

Get a value from the database by key. The optional options object may contain:

  • keyEncoding: custom key encoding for this operation, used to encode the key.
  • valueEncoding: custom value encoding for this operation, used to decode the value.

The callback function will be called with an error if the operation failed. If the key was not found, the error will have code LEVEL_NOT_FOUND. If successful the first argument will be null and the second argument will be the value. If no callback is provided, a promise is returned.

db.getMany(keys[, options][, callback])

Get multiple values from the database by an array of keys. The optional options object may contain:

  • keyEncoding: custom key encoding for this operation, used to encode the keys.
  • valueEncoding: custom value encoding for this operation, used to decode values.

The callback function will be called with an error if the operation failed. If successful the first argument will be null and the second argument will be an array of values with the same order as keys. If a key was not found, the relevant value will be undefined. If no callback is provided, a promise is returned.

db.put(key, value[, options][, callback])

Add a new entry or overwrite an existing entry. The optional options object may contain:

  • keyEncoding: custom key encoding for this operation, used to encode the key.
  • valueEncoding: custom value encoding for this operation, used to encode the value.

The callback function will be called with no arguments if the operation was successful or with an error if it failed. If no callback is provided, a promise is returned.

db.del(key[, options][, callback])

Delete an entry by key. The optional options object may contain:

  • keyEncoding: custom key encoding for this operation, used to encode the key.

The callback function will be called with no arguments if the operation was successful or with an error if it failed. If no callback is provided, a promise is returned.

db.batch(operations[, options][, callback])

Perform multiple put and/or del operations in bulk. The operations argument must be an array containing a list of operations to be executed sequentially, although as a whole they are performed as an atomic operation.

Each operation must be an object with at least a type property set to either 'put' or 'del'. If the type is 'put', the operation must have key and value properties. It may optionally have keyEncoding and / or valueEncoding properties to encode keys or values with a custom encoding for just that operation. If the type is 'del', the operation must have a key property and may optionally have a keyEncoding property.

An operation of either type may also have a sublevel property, to prefix the key of the operation with the prefix of that sublevel. This allows atomically committing data to multiple sublevels. Keys and values will be encoded by the sublevel, to the same effect as a sublevel.batch(..) call. In the following example, the first value will be encoded with 'json' rather than the default encoding of db:

const people = db.sublevel('people', { valueEncoding: 'json' })
const nameIndex = db.sublevel('names')

await db.batch([{
  type: 'put',
  sublevel: people,
  key: '123',
  value: {
    name: 'Alice'
  }
}, {
  type: 'put',
  sublevel: nameIndex,
  key: 'Alice',
  value: '123'
}])

The optional options object may contain:

  • keyEncoding: custom key encoding for this batch, used to encode keys.
  • valueEncoding: custom value encoding for this batch, used to encode values.

Encoding properties on individual operations take precedence. In the following example, the first value will be encoded with the 'utf8' encoding and the second with 'json'.

await db.batch([
  { type: 'put', key: 'a', value: 'foo' },
  { type: 'put', key: 'b', value: 123, valueEncoding: 'json' }
], { valueEncoding: 'utf8' })

The callback function will be called with no arguments if the batch was successful or with an error if it failed. If no callback is provided, a promise is returned.

chainedBatch = db.batch()

Create a chained batch, when batch() is called with zero arguments. A chained batch can be used to build and eventually commit an atomic batch of operations. Depending on how it's used, it is possible to obtain greater performance with this form of batch(). On browser-level however, it is just sugar.

await db.batch()
  .del('bob')
  .put('alice', 361)
  .put('kim', 220)
  .write()

iterator = db.iterator([options])

Create an iterator. The optional options object may contain the following range options to control the range of entries to be iterated:

  • gt (greater than) or gte (greater than or equal): define the lower bound of the range to be iterated. Only entries where the key is greater than (or equal to) this option will be included in the range. When reverse is true the order will be reversed, but the entries iterated will be the same.
  • lt (less than) or lte (less than or equal): define the higher bound of the range to be iterated. Only entries where the key is less than (or equal to) this option will be included in the range. When reverse is true the order will be reversed, but the entries iterated will be the same.
  • reverse (boolean, default: false): iterate entries in reverse order. Beware that a reverse seek can be slower than a forward seek.
  • limit (number, default: Infinity): limit the number of entries yielded. This number represents a maximum number of entries and will not be reached if the end of the range is reached first. A value of Infinity or -1 means there is no limit. When reverse is true the entries with the highest keys will be returned instead of the lowest keys.

The gte and lte range options take precedence over gt and lt respectively. If no range options are provided, the iterator will visit all entries of the database, starting at the lowest key and ending at the highest key (unless reverse is true). In addition to range options, the options object may contain:

  • keys (boolean, default: true): whether to return the key of each entry. If set to false, the iterator will yield keys that are undefined. Prefer to use db.keys() instead.
  • values (boolean, default: true): whether to return the value of each entry. If set to false, the iterator will yield values that are undefined. Prefer to use db.values() instead.
  • keyEncoding: custom key encoding for this iterator, used to encode range options, to encode seek() targets and to decode keys.
  • valueEncoding: custom value encoding for this iterator, used to decode values.

πŸ“Œ To instead consume data using streams, see level-read-stream and level-web-stream.

keyIterator = db.keys([options])

Create a key iterator, having the same interface as db.iterator() except that it yields keys instead of entries. If only keys are needed, using db.keys() may increase performance because values won't have to fetched, copied or decoded. Options are the same as for db.iterator() except that db.keys() does not take keys, values and valueEncoding options.

// Iterate lazily
for await (const key of db.keys({ gt: 'a' })) {
  console.log(key)
}

// Get all at once. Setting a limit is recommended.
const keys = await db.keys({ gt: 'a', limit: 10 }).all()

valueIterator = db.values([options])

Create a value iterator, having the same interface as db.iterator() except that it yields values instead of entries. If only values are needed, using db.values() may increase performance because keys won't have to fetched, copied or decoded. Options are the same as for db.iterator() except that db.values() does not take keys and values options. Note that it does take a keyEncoding option, relevant for the encoding of range options.

// Iterate lazily
for await (const value of db.values({ gt: 'a' })) {
  console.log(value)
}

// Get all at once. Setting a limit is recommended.
const values = await db.values({ gt: 'a', limit: 10 }).all()

db.clear([options][, callback])

Delete all entries or a range. Not guaranteed to be atomic. Accepts the following options (with the same rules as on iterators):

  • gt (greater than) or gte (greater than or equal): define the lower bound of the range to be deleted. Only entries where the key is greater than (or equal to) this option will be included in the range. When reverse is true the order will be reversed, but the entries deleted will be the same.
  • lt (less than) or lte (less than or equal): define the higher bound of the range to be deleted. Only entries where the key is less than (or equal to) this option will be included in the range. When reverse is true the order will be reversed, but the entries deleted will be the same.
  • reverse (boolean, default: false): delete entries in reverse order. Only effective in combination with limit, to delete the last N entries.
  • limit (number, default: Infinity): limit the number of entries to be deleted. This number represents a maximum number of entries and will not be reached if the end of the range is reached first. A value of Infinity or -1 means there is no limit. When reverse is true the entries with the highest keys will be deleted instead of the lowest keys.
  • keyEncoding: custom key encoding for this operation, used to encode range options.

The gte and lte range options take precedence over gt and lt respectively. If no options are provided, all entries will be deleted. The callback function will be called with no arguments if the operation was successful or with an error if it failed. If no callback is provided, a promise is returned.

sublevel = db.sublevel(name[, options])

Create a sublevel that has the same interface as db (except for additional methods specific to classic-level or browser-level) and prefixes the keys of operations before passing them on to db. The name argument is required and must be a string.

const example = db.sublevel('example')

await example.put('hello', 'world')
await db.put('a', '1')

// Prints ['hello', 'world']
for await (const [key, value] of example.iterator()) {
  console.log([key, value])
}

Sublevels effectively separate a database into sections. Think SQL tables, but evented, ranged and real-time! Each sublevel is an AbstractLevel instance with its own keyspace, events and encodings. For example, it's possible to have one sublevel with 'buffer' keys and another with 'utf8' keys. The same goes for values. Like so:

db.sublevel('one', { valueEncoding: 'json' })
db.sublevel('two', { keyEncoding: 'buffer' })

An own keyspace means that sublevel.iterator() only includes entries of that sublevel, sublevel.clear() will only delete entries of that sublevel, and so forth. Range options get prefixed too.

Fully qualified keys (as seen from the parent database) take the form of prefix + key where prefix is separator + name + separator. If name is empty, the effective prefix is two separators. Sublevels can be nested: if db is itself a sublevel then the effective prefix is a combined prefix, e.g. '!one!!two!'. Note that a parent database will see its own keys as well as keys of any nested sublevels:

// Prints ['!example!hello', 'world'] and ['a', '1']
for await (const [key, value] of db.iterator()) {
  console.log([key, value])
}

πŸ“Œ The key structure is equal to that of subleveldown which offered sublevels before they were built-in to abstract-level. This means that an abstract-level sublevel can read sublevels previously created with (and populated by) subleveldown.

Internally, sublevels operate on keys that are either a string, Buffer or Uint8Array, depending on parent database and choice of encoding. Which is to say: binary keys are fully supported. The name must however always be a string and can only contain ASCII characters.

The optional options object may contain:

  • separator (string, default: '!'): Character for separating sublevel names from user keys and each other. Must sort before characters used in name. An error will be thrown if that's not the case.
  • keyEncoding (string or object, default 'utf8'): encoding to use for keys
  • valueEncoding (string or object, default 'utf8'): encoding to use for values.

The keyEncoding and valueEncoding options are forwarded to the AbstractLevel constructor and work the same, as if a new, separate database was created. They default to 'utf8' regardless of the encodings configured on db. Other options are forwarded too but abstract-level (and therefor level) has no relevant options at the time of writing. For example, setting the createIfMissing option will have no effect. Why is that?

Like regular databases, sublevels open themselves but they do not affect the state of the parent database. This means a sublevel can be individually closed and (re)opened. If the sublevel is created while the parent database is opening, it will wait for that to finish. If the parent database is closed, then opening the sublevel will fail and subsequent operations on the sublevel will yield errors with code LEVEL_DATABASE_NOT_OPEN.

chainedBatch

chainedBatch.put(key, value[, options])

Queue a put operation on this batch, not committed until write() is called. This will throw a LEVEL_INVALID_KEY or LEVEL_INVALID_VALUE error if key or value is invalid. The optional options object may contain:

  • keyEncoding: custom key encoding for this operation, used to encode the key.
  • valueEncoding: custom value encoding for this operation, used to encode the value.
  • sublevel (sublevel instance): act as though the put operation is performed on the given sublevel, to similar effect as sublevel.batch().put(key, value). This allows atomically committing data to multiple sublevels. The key will be prefixed with the prefix of the sublevel, and the key and value will be encoded by the sublevel (using the default encodings of the sublevel unless keyEncoding and / or valueEncoding are provided).

chainedBatch.del(key[, options])

Queue a del operation on this batch, not committed until write() is called. This will throw a LEVEL_INVALID_KEY error if key is invalid. The optional options object may contain:

  • keyEncoding: custom key encoding for this operation, used to encode the key.
  • sublevel (sublevel instance): act as though the del operation is performed on the given sublevel, to similar effect as sublevel.batch().del(key). This allows atomically committing data to multiple sublevels. The key will be prefixed with the prefix of the sublevel, and the key will be encoded by the sublevel (using the default key encoding of the sublevel unless keyEncoding is provided).

chainedBatch.clear()

Clear all queued operations on this batch.

chainedBatch.write([options][, callback])

Commit the queued operations for this batch. All operations will be written atomically, that is, they will either all succeed or fail with no partial commits.

There are no options (that are common between classic-level and browser-level). Note that write() does not take encoding options. Those can only be set on put() and del().

The callback function will be called with no arguments if the batch was successful or with an error if it failed. If no callback is provided, a promise is returned.

After write() or close() has been called, no further operations are allowed.

chainedBatch.close([callback])

Free up underlying resources. This should be done even if the chained batch has zero queued operations. Automatically called by write() so normally not necessary to call, unless the intent is to discard a chained batch without committing it. The callback function will be called with no arguments. If no callback is provided, a promise is returned. Closing the batch is an idempotent operation, such that calling close() more than once is allowed and makes no difference.

chainedBatch.length

The number of queued operations on the current batch.

chainedBatch.db

A reference to the database that created this chained batch.

iterator

An iterator allows one to lazily read a range of entries stored in the database. The entries will be sorted by keys in lexicographic order (in other words: byte order) which in short means key 'a' comes before 'b' and key '10' comes before '2'.

A classic-level iterator reads from a snapshot of the database, created at the time db.iterator() was called. This means the iterator will not see the data of simultaneous write operations. A browser-level iterator does not offer such guarantees, as is indicated by db.supports.snapshots. That property will be true in Node.js and false in browsers.

Iterators can be consumed with for await...of and iterator.all(), or by manually calling iterator.next() or nextv() in succession. In the latter case, iterator.close() must always be called. In contrast, finishing, throwing, breaking or returning from a for await...of loop automatically calls iterator.close(), as does iterator.all().

An iterator reaches its natural end in the following situations:

  • The end of the database has been reached
  • The end of the range has been reached
  • The last iterator.seek() was out of range.

An iterator keeps track of calls that are in progress. It doesn't allow concurrent next(), nextv() or all() calls (including a combination thereof) and will throw an error with code LEVEL_ITERATOR_BUSY if that happens:

// Not awaited and no callback provided
iterator.next()

try {
  // Which means next() is still in progress here
  iterator.all()
} catch (err) {
  console.log(err.code) // 'LEVEL_ITERATOR_BUSY'
}

for await...of iterator

Yields entries, which are arrays containing a key and value. The type of key and value depends on the options passed to db.iterator().

try {
  for await (const [key, value] of db.iterator()) {
    console.log(key)
  }
} catch (err) {
  console.error(err)
}

iterator.next([callback])

Advance to the next entry and yield that entry. If an error occurs, the callback function will be called with an error. Otherwise, the callback receives null, a key and a value. The type of key and value depends on the options passed to db.iterator(). If the iterator has reached its natural end, both key and value will be undefined.

If no callback is provided, a promise is returned for either an entry array (containing a key and value) or undefined if the iterator reached its natural end.

Note: iterator.close() must always be called once there's no intention to call next() or nextv() again. Even if such calls yielded an error and even if the iterator reached its natural end. Not closing the iterator will result in memory leaks and may also affect performance of other operations if many iterators are unclosed and each is holding a snapshot of the database.

iterator.nextv(size[, options][, callback])

Advance repeatedly and get at most size amount of entries in a single call. Can be faster than repeated next() calls. The size argument must be an integer and has a soft minimum of 1. There are no options at the moment.

If an error occurs, the callback function will be called with an error. Otherwise, the callback receives null and an array of entries, where each entry is an array containing a key and value. The natural end of the iterator will be signaled by yielding an empty array. If no callback is provided, a promise is returned.

const iterator = db.iterator()

while (true) {
  const entries = await iterator.nextv(100)

  if (entries.length === 0) {
    break
  }

  for (const [key, value] of entries) {
    // ..
  }
}

await iterator.close()

iterator.all([options][, callback])

Advance repeatedly and get all (remaining) entries as an array, automatically closing the iterator. Assumes that those entries fit in memory. If that's not the case, instead use next(), nextv() or for await...of. There are no options at the moment. If an error occurs, the callback function will be called with an error. Otherwise, the callback receives null and an array of entries, where each entry is an array containing a key and value. If no callback is provided, a promise is returned.

const entries = await db.iterator({ limit: 100 }).all()

for (const [key, value] of entries) {
  // ..
}

iterator.seek(target[, options])

Seek to the key closest to target. Subsequent calls to iterator.next(), nextv() or all() (including implicit calls in a for await...of loop) will yield entries with keys equal to or larger than target, or equal to or smaller than target if the reverse option passed to db.iterator() was true.

The optional options object may contain:

  • keyEncoding: custom key encoding, used to encode the target. By default the keyEncoding option of the iterator is used or (if that wasn't set) the keyEncoding of the database.

If range options like gt were passed to db.iterator() and target does not fall within that range, the iterator will reach its natural end.

iterator.close([callback])

Free up underlying resources. The callback function will be called with no arguments. If no callback is provided, a promise is returned. Closing the iterator is an idempotent operation, such that calling close() more than once is allowed and makes no difference.

If a next() ,nextv() or all() call is in progress, closing will wait for that to finish. After close() has been called, further calls to next() ,nextv() or all() will yield an error with code LEVEL_ITERATOR_NOT_OPEN.

iterator.db

A reference to the database that created this iterator.

iterator.count

Read-only getter that indicates how many keys have been yielded so far (by any method) excluding calls that errored or yielded undefined.

iterator.limit

Read-only getter that reflects the limit that was set in options. Greater than or equal to zero. Equals Infinity if no limit, which allows for easy math:

const hasMore = iterator.count < iterator.limit
const remaining = iterator.limit - iterator.count

keyIterator

A key iterator has the same interface as iterator except that its methods yield keys instead of entries. For the keyIterator.next(callback) method, this means that the callback will receive two arguments (an error and key) instead of three. Usage is otherwise the same.

valueIterator

A value iterator has the same interface as iterator except that its methods yield values instead of entries. For the valueIterator.next(callback) method, this means that the callback will receive two arguments (an error and value) instead of three. Usage is otherwise the same.

sublevel

A sublevel is an instance of the AbstractSublevel class, which extends AbstractLevel and thus has the same API as documented above. Sublevels have a few additional properties.

sublevel.prefix

Prefix of the sublevel. A read-only string property.

const example = db.sublevel('example')
const nested = example.sublevel('nested')

console.log(example.prefix) // '!example!'
console.log(nested.prefix) // '!example!!nested!'

sublevel.db

Parent database. A read-only property.

const example = db.sublevel('example')
const nested = example.sublevel('nested')

console.log(example.db === db) // true
console.log(nested.db === db) // true

Contributing

Level/level is an OPEN Open Source Project. This means that:

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.

See the Contribution Guide for more details.

Donate

Support us with a monthly donation on Open Collective and help us continue our work.

License

MIT

level-ttl's People

Contributors

alessioalex avatar deanlandolt avatar dependabot[bot] avatar dey-dey avatar greenkeeper[bot] avatar jfromaniello avatar mafintosh avatar max-mapper avatar mcollina avatar ralphtheninja avatar rvagg avatar tehshrike avatar thebergamo avatar vweevers avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

level-ttl's Issues

An in-range update of tape is breaking the build 🚨

The devDependency tape was updated from 4.9.2 to 4.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 60 commits.

  • 34b1832 v4.10.0
  • 6209882 Merge all orphaned tags: 'v1.1.2', 'v2.0.2', 'v2.1.1', 'v2.2.2', 'v2.3.3', 'v2.4.3', 'v2.5.1', 'v2.6.1', 'v2.7.3', 'v2.8.1', 'v2.9.1', 'v2.10.3', 'v2.11.1', 'v2.13.4', 'v2.14.0', 'v2.14.1', 'v3.6.1'
  • 82e7b26 [Deps] update glob
  • 9e3d25e [Dev Deps] update eslint, js-yaml
  • fd807f5 v1.1.2
  • eddbff5 v2.14.1
  • 6ce09d9 Minor test tweaks due to whitespace differences in v2 vs v4.
  • 71af8ba gitignore node_modules
  • 4c0d9e6 Merge pull request #268 from ljharb/throws_non_function_should_fail
  • d0a675f v3.6.1
  • d22b5fc Minor test tweaks due to output differences in v1 vs v4.
  • 8b3c1b7 Add missing concat-stream devDep
  • 3495543 gitignore node_modules
  • db81846 Merge pull request #268 from ljharb/throws_non_function_should_fail
  • 7ed6651 Minor test tweaks due to whitespace differences in v3 vs v4.

There are 60 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Crash on timeout

I'm able to put and get data from db using level-ttl, but it crashes on timeout:

/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:37
  if (db.levelup.isOpen())
                 ^
TypeError: Object #<EventEmitter> has no method 'isOpen'
    at new LevelUPDOWNIterator (/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:37:18)
    at Object.iteratorFactory [as factory] (/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:240:20)
    at Object.wrappedFactory [as factory] (/n/node_modules/level-ttl/node_modules/level-spaces/level-spaces.js:131:26)
    at LevelUPDOWN._iterator (/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:249:14)
    at LevelUPDOWN.AbstractLevelDOWN.iterator (/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/node_modules/abstract-leveldown/abstract-leveldown.js:224:17)
    at /n/node_modules/level-ttl/node_modules/level-spaces/node_modules/levelup/lib/levelup.js:400:24
    at new ReadStream (/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/levelup/lib/read-stream.js:68:22)
    at LevelUP.readStream.LevelUP.createReadStream (/n/node_modules/level-ttl/node_modules/level-spaces/node_modules/levelup/lib/levelup.js:396:10)
    at Timer.<anonymous> (/n/node_modules/level-ttl/level-ttl.js:19:17)
    at Timer.wrapper [as ontimeout] (timers.js:261:14)

My code looks like this:

var ttl = require('level-ttl');
var verifiedTokens = ttl(db.sublevel('verifiedTokens'), {});

Has anyone else had this problem? Any ideas?

Cannot call method 'iterator' of undefined

I'm trying to do something like this:

var db = levelup(__dirname + '/../cache.db', {valueEncoding: 'json'});
db =  sublevel(db);
var foobar = ttl(db.sublevel('foobar'))

but I get this error:

TypeError: Cannot call method 'iterator' of undefined
    at start (/my-project/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:34:41)
    at new LevelUPDOWNIterator (/my-project/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:38:12)
    at Object.iteratorFactory [as factory] (/my-project/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:240:20)
    at Object.wrappedFactory [as factory] (/my-project/node_modules/level-ttl/node_modules/level-spaces/level-spaces.js:131:26)
    at LevelUPDOWN._iterator (/my-project/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/level-updown.js:249:14)
    at LevelUPDOWN.AbstractLevelDOWN.iterator (/my-project/node_modules/level-ttl/node_modules/level-spaces/node_modules/level-updown/node_modules/abstract-leveldown/abstract-leveldown.js:224:17)
    at /my-project/node_modules/levelup/lib/levelup.js:400:24
    at new ReadStream (/my-project/node_modules/levelup/lib/read-stream.js:68:22)
    at LevelUP.readStream.LevelUP.createReadStream (/my-project/node_modules/levelup/lib/levelup.js:396:10)
    at Timer.<anonymous> (/my-project/node_modules/level-ttl/level-ttl.js:19:17)

My package.json has this:

    "level-sublevel": "~6.4.4",
    "level-ttl": "~2.2.0",
    "leveldown": "~0.10.4",
    "levelup": "~0.18.6",

I've tried other combinations like:

db =  ttl(sublevel(db));

and:

db =  sublevel(ttl(db));

But I always get the same error.

An in-range update of tape is breaking the build 🚨

The devDependency tape was updated from 4.10.1 to 4.10.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 7 commits.

  • 2c6818a v4.10.2
  • 15b2dfc [fix] don't consider 'ok' of todo tests in exit code
  • 9ec3a0f [Dev Deps] update eslint, js-yaml
  • 3f337d1 [meta] set save-prefix to ~ (meant for runtime deps)
  • c30e492 [Deps] update glob, resolve
  • 25b4a24 Minor punctuation/highlighting improvement
  • c481dae [Refactor] Removed never-read inErrorState from index.js

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

tests fail randomly

It probably varies depending on your computer but according to my measurements they happen about every 25th on average, i.e. 4 out of 100 tests (on my machine that is).

# test prolong entry life with additional put
ok 64 no error on open()
ok 65 no error
ok 66 contains {bar, barvalue}
ok 67 contains {foo, foovalue}
ok 68 contains {\xffttl\xff\d{13}!bar, bar}
ok 69 contains {ΓΏttlΓΏbar, \d{13}}
ok 70 no error
ok 71 contains {bar, barvalue}
ok 72 contains {foo, foovalue}
ok 73 contains {\xffttl\xff\d{13}!bar, bar}
ok 74 contains {ΓΏttlΓΏbar, \d{13}}
ok 75 no error
ok 76 contains {bar, barvalue}
ok 77 contains {foo, foovalue}
ok 78 contains {\xffttl\xff\d{13}!bar, bar}
ok 79 contains {ΓΏttlΓΏbar, \d{13}}
ok 80 no error
ok 81 contains {bar, barvalue}
ok 82 contains {foo, foovalue}
not ok 83 does not contain {\xffttl\xff\d{13}!bar, bar}
  ---
    operator: fail
    at: contains (/home/lms/src/leveldb-repos/node-level-ttl/test.js:63:12)
  ...
not ok 84 does not contain {ΓΏttlΓΏbar, \d{13}}
  ---
    operator: fail
    at: contains (/home/lms/src/leveldb-repos/node-level-ttl/test.js:63:12)
  ...

Is there some way we can make the tests more stable and less timing critical?

This feels like a race condition where either a batch of ttl meta data keys haven't had the time to be written before they are being read by the test or that they have in fact been deleted just before we're reading them in the tests (e.g. in db2arr(createReadStream, t, function (err, arr) {})

An in-range update of standard is breaking the build 🚨

The devDependency standard was updated from 13.0.1 to 13.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/standard-13.0.2 at 90.146% (Details).

Commits

The new version differs by 7 commits.

  • 9539d71 13.0.2
  • 9b9d0fc changelog
  • d1d0b7a Fix global installs: standard-engine@~11.0.1
  • edce3f3 Merge pull request #1323 from standard/greenkeeper/standard-engine-11.0.0
  • 2f3c712 fix tests for standard-engine 11
  • ae04dbb Cleanup the readme
  • 0474066 fix(package): update standard-engine to version 11.0.0

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of subleveldown is breaking the build 🚨

The devDependency subleveldown was updated from 4.0.0 to 4.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

subleveldown is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Release Notes for v4.1.0

Changed

  • Upgrade nyc devDependency from ^13.3.0 to ^14.0.0 (#63) (@vweevers)

Added

Commits

The new version differs by 8 commits.

  • aa16a28 4.1.0
  • 89e8d65 Prepare 4.1.0
  • 67f3925 Support seeking (#66)
  • 7e2dba4 Revert "feat: add _seek support" - needed review
  • f90c2cc feat: add _seek support
  • 49ff8e3 Fix Level badge
  • 2113f45 Upgrade nyc devDependency from ^13.3.0 to ^14.0.0 (#63)
  • 9568ed2 Remove link to dead website

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Compatibility with sublevel

This module is not compatible with sublevel anymore :(, it complains about missing isOpen() methods and so on. However, I'm not sure that compatibility with sublevel is still something we aim to achieve with this.

I also tried running it on top of different 'spaces', but with no luck, I'm not getting the right stuff out if it (I'm using a custom encoding for values).

An in-range update of dependency-check is breaking the build 🚨

The devDependency dependency-check was updated from 3.3.1 to 3.3.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

dependency-check is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

  • Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

  • engines was only updated if it defined a single version, not a range.
  • .nvmrc was updated to Node.js 10
  • .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected πŸ€–


FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of slump is breaking the build 🚨

Version 2.0.4 of slump was just published.

Branch Build failing 🚨
Dependency slump
Current Version 2.0.3
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

slump is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 6 commits.

  • 1e35d0c 2.0.4
  • 6c3a8ee tweak readme
  • 134f8d2 update node versions
  • d996631 update badges
  • 00cf455 Merge pull request #4 from ralphtheninja/greenkeeper/standard-11.0.0
  • ba4ec76 chore(package): update standard to version 11.0.0

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of hallmark is breaking the build 🚨

The devDependency hallmark was updated from 1.1.0 to 1.1.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

hallmark is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 2 commits.

  • ecd5d73 1.1.1
  • 48c7abc Restore previous repo behavior of remark-validate-links (#32)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of level-sublevel is breaking the build 🚨

Version 6.6.2 of level-sublevel was just published.

Branch Build failing 🚨
Dependency level-sublevel
Current Version 6.6.1
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

level-sublevel is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 4 commits.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

db._ttl.sub.batch calls level-ttl#batch

The db._ttl.sub.batch call here ends up calling level-ttl#batch here because:

  1. level-updown#_batch calls levelup#batch here and
  2. levelup#batch is rebound by level-ttl here

Now, this works because the options object doesn't have any ttl property set when level-ttl#batch is called internally (an internal call would be e.g. db._ttl.sub.batch()). However, if we want to be able to implement a defaultTTL type of use case, this wouldn't work because we would try to put ttl information on the ttl keys, which would end up in here again and we have an infinite loop.

This can be addressed in several ways but I'm not entirely sure what the best way is, so I'd like to know your guys opinion on this if you have a minute.

  1. Either we add a key check in level-ttl#batch to have it ignore ttl meta data keys. This would mean checking against '\xff' which is a leaky abstraction on level-spaces.
  2. Make sure that level-updown#_batch always calls the original levelup#batch regardless if it has been patched by level-ttl or not (see rvagg/archived-level-updown#2)

Thoughts?

/cc @rvagg @ekristen @mcollina @hij1nx

An in-range update of xtend is breaking the build 🚨

The dependency xtend was updated from 4.0.1 to 4.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

xtend is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/xtend-4.0.2 at 90.146% (Details).

Commits

The new version differs by 9 commits.

  • 37816c0 4.0.2
  • c839f32 Merge pull request #31 from DDRBoxman/master
  • 69a08ab Merge pull request #39 from LinusU/prototype-pollution-test
  • 9655c70 Add tests for protoype pollution
  • 82bd7f0 Merge pull request #36 from jpls93/patch-1
  • a1c126f Update README.md
  • 5fa453d Merge pull request #33 from sarathms/drop_makefile
  • 016c51b dropped Makefile added for obsolete browser compat build step
  • c8b4ff1 Fix spelling / content of License

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Breakout ltest() function into separate module?

I like the ltest() function in test.js a lot. It's a very common use case that you want to test something and you want a fresh db, which is closed and cleaned up automatically.

@rvagg Would you mind if I stole your code? :) I'm thinking this would be a good fit together with level-test instead of using levelup (so there would be automatic support for in memory databases) and it should also probably be slightly more generic, i.e. remove the calls to ttl() and fixtape() (btw what does that call do?).

Another cool thing would be if it was test agnostic and could be configured with a test function, so you could use tap or tape or whatever.

is level-ttl suppose to work with chained batch?

var levelup = require('levelup')
var levelTtl = require('level-ttl')

var db = levelTtl( levelup('db') )

var batch = db.batch()

batch.put(Date.now(), '2',  { valueEncoding: 'json', ttl: 12312 })

batch.write(function () {
    console.log(123)
})

results in:

events.js:85
      throw er; // Unhandled 'error' event
            ^
WriteError: batch() requires an array argument
    at writeError (/xxxxx/node_modules/levelup/lib/levelup.js:181:8)
    at LevelUP.batch (/xxxxx/node_modules/levelup/lib/levelup.js:304:12)
    at batch (/xxxxx/node_modules/level-ttl/level-ttl.js:275:17)
    at Object.<anonymous> (/xxxxx/index.js:6:16)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)
    at startup (node.js:129:16)

removing level-ttl wrapper makes this code work.

Versions:
"level-ttl": "^3.0.3",
"leveldown": "^0.10.4",
"levelup": "^0.19.0",

An in-range update of dependency-check is breaking the build 🚨

The devDependency dependency-check was updated from 3.3.0 to 3.3.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

dependency-check is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Listening for expiring keys.

Is there any way to listen for an expiring key event? I did not see it in the documentation but wanted to double check. I tried using db.on('del',...) but no luck. thanks

An in-range update of slump is breaking the build 🚨

Version 2.0.3 of slump was just published.

Branch Build failing 🚨
Dependency slump
Current Version 2.0.2
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

slump is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 5 commits.

  • 37e8322 2.0.3
  • 58b0058 bump sodium-universal
  • 5906c88 Merge pull request #2 from ralphtheninja/greenkeeper/initial
  • 2a9989b Update README.md
  • 321363b docs(readme): add Greenkeeper badge

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

duplicate "!ttl!x!timestamp|foo" entries causing unwanted deletes

My application does something like:

db.put("foo", "xx", {ttl: ms('1h') });

After sometime running (12hs), I eventually end up with duplicated entries with the key format !ttl!x!timestamp|foo which causes an unwanted delete before the time that is expected to be deleted

I took an snapshot of my db and I ran the following command:

 ./leveldb_keys ~/db-snapshot/ | grep '!ttl!x!' | cut -c 23- | sort | uniq -c | grep -v '^ *1 '
   2 foo
   2 bar
   2 baz

I was having this issue with v2 yesterday (warning it has a different format for the key of these entries). I upgraded to v3 and I continue to have the same problem. If I leave the application running more time I eventually end up having more than 2 of these things. The application didn't crash at any time, etc.

Can you think on any kind of race condition between ttlon/off? Why ttloff might not be working on some circustance?

If someone is using this module in production with traffic, can ran the above command on test if it has duped entries will be awesome.

Thanks

An in-range update of standard is breaking the build 🚨

Version 12.0.1 of standard was just published.

Branch Build failing 🚨
Dependency standard
Current Version 12.0.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/standard-12.0.1 at 90.146% (Details).

Commits

The new version differs by 8 commits.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of hallmark is breaking the build 🚨

The devDependency hallmark was updated from 1.1.1 to 1.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

hallmark is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 6 commits.

  • e0b7304 1.2.0
  • 242ff83 Remove (already disabled) remark-lint-no-dead-urls (closes #17)
  • c6ec6ab Skip remark-git-contributors in lint mode (#33)
  • 80131b3 Pass repository into remark-github as well (skip reading package.json twice)
  • 1e14759 Refactor options a tiny bit
  • 71ddd8e Add comments to unified-engine options

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

discussion: async prehooks

I'm looking into async pre hooks again,
following up on the async2 branch on level-hooks,
and this was the other use case that someone had implemented
that needs to be considered.

reading the code i'm seeing some room for improvement:

basically, you have something like this:

put = function (key, value, cb) {
  //delete current ttl record
  ttloff(key, function () {

    ttlon(key, function () {
      _put(key, value, cb)
    })
  })
}

this does three round trips to the db before actually doing the put.
what would be way better would to make it more like this

put = function (key, value, cb) {
  var batch = [
    {key: key, value: value, type: 'put'},
    {key: key, value: timestamp() + ttl, type: 'put', prefix: ttlDb
]
  ttlDb.get(key, function (err, exp) {
    batch.push({key: exp + '\x00' + key, type: del})
    //perform a batch instead of a put.
    db.batch(batch, cb)
  })
}

Or something to that effect, combined into a nicer prehook api.

I'm thinking: on put/del/batch perform a read (arbitrary - but there is a single callback)
then, you get a prehook, as per current level-hooks, but you'll have access to whatever was returned in the read stage.

And so, you'd be able to read the current value, merge with the value you are currently inserting, and optionally, add ops to the batch.

An in-range update of standard is breaking the build 🚨

The devDependency standard was updated from 13.0.2 to 13.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/standard-13.1.0 at 90.146% (Details).

Commits

The new version differs by 7 commits.

  • ef2351a Update AUTHORS.md
  • 60b616f 13.1.0
  • 8493c9d Update CHANGELOG.md
  • 588e505 Merge pull request #1337 from standard/greenkeeper/eslint-6.1.0
  • 9040ae8 fix(package): update eslint to version 6.1.0
  • a263dfc Merge pull request #1336 from epixian/patch-1
  • 15a1105 added oxford comma for consistency with next line

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of nyc is breaking the build 🚨

The devDependency nyc was updated from 14.0.0 to 14.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

nyc is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/nyc-14.1.0 at 90.146% (Details).

Commits

The new version differs by 15 commits.

  • c5d90fa chore(release): 14.1.0
  • 5cc05f4 chore: Update dependencies
  • 1e39ae1 chore: Refresh snapshots, update test/config-override.js to use helpers (#1085)
  • 3d9eaa4 fix: Purge source-map cache before reporting if cache is disabled. (#1080)
  • 132a074 feat: Add support for env.NYC_CONFIG_OVERRIDE (#1077)
  • 6fc109f chore: node.js 12 compatibility for object snapshot test. (#1084)
  • a7bc7ae fix: Use correct config property for parser plugins (#1082)
  • 600c867 chore: Convert some tap tests to run parallel and use snapshots. (#1075)
  • 56591fa docs: instrument docs update [skip ci] (#1063)
  • ca84c42 docs(codecov): favour npx over installing locally [skip ci] (#1074)
  • 85c1eac chore: Add test for nyc --no-clean. (#1071)
  • 21fb2c8 fix: Exit with code 1 when nyc doesn't know what to do. (#1070)
  • 0f745ca chore: Use class to declare NYC (#1069)
  • ca37ffa feat: add support for yaml configuration file (#1054)
  • c4fcf5e fix: Do not crash when nyc is run inside itself. (#1068)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of tape is breaking the build 🚨

The devDependency tape was updated from 4.10.2 to 4.11.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/tape-4.11.0 at 90.146% (Details).

Release Notes for v4.11.0
  • [New] Add descriptive messages for skipped asserts (#476)
  • [Fix] emit skipped tests as objects (#473)
  • [Refactor] use !! over Boolean()
  • [meta] clean up license so github can detect it
  • [Deps] update inherits, resolve
  • [Tests] add tests for 'todo' exit codes (#471)
Commits

The new version differs by 8 commits.

  • 2b5046e v4.11.0
  • 9526c2e [Deps] update inherits, resolve
  • 32b5948 [Refactor] use !! over Boolean()
  • 838d995 [New] Add descriptive messages for skipped asserts
  • 861cf55 [meta] clean up license so github can detect it
  • 8d5dc2f [Fix] emit skipped tests as objects
  • a5006ce [lint] enforce consistent semicolon usage
  • c6c4ace [Tests] add tests for 'todo' exit codes

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of tape is breaking the build 🚨

Version 4.9.1 of tape was just published.

Branch Build failing 🚨
Dependency tape
Current Version 4.9.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 10 commits.

  • 050b318 v4.9.1
  • 73232c0 [Dev Deps] update js-yaml
  • 8a2d29b [Deps] update has, for-each, resolve, object-inspect
  • c6f5313 [Tests] add eclint and eslint, to enforce a consistent style
  • 45788a5 [Dev Deps] update concat-stream
  • ec4a71d [fix] Fix bug in functionName regex during stack parsing
  • 7261ccc Merge pull request #433 from mcnuttandrew/add-trb
  • 6cbc53e Add tap-react-browser
  • 9d501ff [Dev Deps] use ~ for dev deps; update to latest nonbreaking
  • 24e0a8d Fix spelling of "parameterize"

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of nyc is breaking the build 🚨

The devDependency nyc was updated from 13.2.0 to 13.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

nyc is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • βœ… coverage/coveralls: First build on greenkeeper/nyc-13.3.0 at 90.146% (Details).

Commits

The new version differs by 4 commits.

  • 747a6c1 chore(release): 13.3.0
  • e8cc59b fix: update dependendencies due to vulnerabilities (#992)
  • 8a5e222 chore: Modernize lib/instrumenters. (#985)
  • dd48410 feat: Support nyc report --check-coverage (#984)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

New release master

I have to hand off responsibility for cutting releases on level-ttl, I use it, but it's not important enough for me to keep it all in my head along with all of the other stuff I have going on so I don't want to hold up quality releases or be a reason for poor quality releases.

I'm proposing @mcollina as new release master, I can npm owner add him if there are no objections and if he (a) has the time to do this and (b) if this module is important enough to him. My second choice would be @ralphtheninja if @mcollina can't do this I think.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.