nothingness

nothingness

A small implementation of an abstract data access object base class. Intended for use with a project built on leveldb, but should work just fine with both relational and documented-oriented stores. Written using as many ES2015 idioms as I could comfortably pick up over the course of writing it.

installation

npm install --save nothingness

usage

Create a DAO:

// thinger-dao.js

// using Babel's module loader for Node
import DAO from 'nothingness'
import { v4 as uuid } from 'node-uuid'

export default class ThingerDAO extends DAO {
  generateID (pojo) {
    // the #yolo uniqueness constraint
    const id = uuid()
    pojo[DAO.idSymbol] = id
    return id
  }
}

Use it to persist and load an object:

// main.js
import ThingerDAO from './thinger-dao.js'
import assert from 'assert'
import Adaptor from '@nothingness/level'

const dao = new ThingerDAO(new Adaptor('./thinger-db'))
const thingy = { type: 'band' }

// uses Bluebird's .nodeify(), so callback or promise chain are fine
dao.save(thingy)
   .then(() => dao.findAll())
   .then(results => assert.deepEqual(
     results,
     [{ type: 'band' }],
     'should only have one item, of type "band"'
   ))
   .then(() => console.log('round trip succeeded!'))
   .catch(err => console.error(err.stack))
   .finally(() => dao.closeDB())

caveats

• Nothingness will attain unity as soon as possible; until then be prepared for fluxes in the void.
• There is no validation in nothingness.
• There is no ORM in nothingness.
• There is no ODM in nothingness.
• There is no SQL nor no-SQL in nothingness; there is only separation (of concerns) and absence (of concrete implementations).

why

Sometimes the objects that are part of a persistence model are used in other parts of an application, and coupling the model to the persistence strategy means that those other packages may now have a bunch of dependencies they don't need. By using the Data Mapper pattern, you can cleanly separate things and have a simpler application maybe?