Code Monkey home page Code Monkey logo

level-ttl's Introduction

level-ttl

Add a ttl (time-to-live) option to levelup for put() and batch().

level badge npm Node version Test Coverage Standard Common Changelog Donate

Table of Contents

Click to expand

Usage

If you are upgrading: please see UPGRADING.md.

Augment levelup to handle a new ttl option on put() and batch() that specifies the number of milliseconds an entry should remain in the data store. After the TTL, the entry will be automatically cleared for you.

Requires levelup, level or one of its variants like level-rocksdb to be installed separately.

const level = require('level')
const ttl = require('level-ttl')

const db = ttl(level('./db'))

// This entry will only stay in the store for 1 hour
db.put('foo', 'bar', { ttl: 1000 * 60 * 60 }, (err) => {
  // ..
})

db.batch([
  // Same for these two entries
  { type: 'put', key: 'foo', value: 'bar' },
  { type: 'put', key: 'bam', value: 'boom' },
  { type: 'del', key: 'w00t' }
], { ttl: 1000 * 60 * 5 }, (err) => {})

If you put the same entry twice, you refresh the TTL to the last put operation. In this way you can build utilities like session managers for your web application where the user's session is refreshed with each visit but expires after a set period of time since their last visit.

Alternatively, for a lower write-footprint you can use the ttl() method that is added to your levelup instance which can serve to insert or update a ttl for any given key in the database - even if that key doesn't exist but may in the future!

db.put('foo', 'bar', (err) => {})
db.ttl('foo', 1000 * 60 * 60, (err) => {})

level-ttl uses an internal scan every 10 seconds by default, this limits the available resolution of your TTL values, possibly delaying a delete for up to 10 seconds. The resolution can be tuned by passing the checkFrequency option to the ttl() initialiser.

// Scan every second
const db = ttl(level('./db'), {
  checkFrequency: 1000
})

Of course, a scan takes some resources, particularly on a data store that makes heavy use of TTLs. If you don't require high accuracy for actual deletions then you can increase the checkFrequency. Note though that a scan only involves invoking a levelup ReadStream that returns only the entries due to expire, so it doesn't have to manually check through all entries with a TTL. As usual, it's best to not do too much tuning until you have you have something worth tuning!

Default TTL

You can set a default ttl value for all your keys by passing the defaultTTL option to the ttl() initialiser. This can be overridden per operation. In the following example A will expire in 15 minutes while B will expire in one minute.

const db = ttl(level('./db'), {
  defaultTTL: 15 * 60 * 1000
})

db.put('A', 'beep', (err) => {})
db.put('B', 'boop', { ttl: 60 * 1000 }, (err) => {})

opts.sub

You can provide a custom storage for the meta data by using the opts.sub property. If it's set, that storage will contain all the ttl meta data. A use case for this would be to avoid mixing data and meta data in the same keyspace, since if it's not set, all data will be sharing the same keyspace.

A db for the data and a separate to store the meta data:

const level = require('level')
const ttl = require('level-ttl')
const meta = level('./meta')

const db = ttl(level('./db'), { sub: meta })

const batch = [
  { type: 'put', key: 'foo', value: 'foo value' },
  { type: 'put', key: 'bar', value: 'bar value' }
]

db.batch(batch, { ttl: 100 }, function (err) {
  db.createReadStream()
    .on('data', function (data) {
      console.log('data', data)
    })
    .on('end', function () {
      meta.createReadStream()
        .on('data', function (data) {
          console.log('meta', data)
        })
    })
})

Shutting down

level-ttl uses a timer to regularly check for expiring entries (don't worry, the whole data store isn't scanned, it's very efficient!). The db.close() method is automatically wired to stop the timer but there is also a more explicit db.stop() method that will stop the timer and not close the underlying levelup instance.

Contributing

Level/level-ttl 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  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

level-ttl's Issues

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 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 🌴

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?

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 🌴

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 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 🌴

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.

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 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 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 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 🌴

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 🌴

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 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.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 🌴

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 🌴

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 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 🌴

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 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 🌴

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 🌴

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 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 🌴

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

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.

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 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 🌴

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 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 🌴

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.

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.