npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

transactional-db

v1.0.3

Published

A library for composing database transactions.

Downloads

3

Readme

transactional-db

Build Status Coverage Status

This library provides composable transactions for RDBMS. Currently only MySQL is supported through the use of mysql. Other databases can be supported by writing an appropriate adapter for their drivers and registering it with this library.

transactional can be used in two ways, but only one is recommended. The first is to use it as a traditional Object Oriented library. It is written using methods that return promises so you don't need to worry about callback hell.

The second is to use the provided DSL to write composable transactions. This is the recommended way to use it and an example of it is shown below. This can even be combined with the instructions of other Free monad DSLs, provided you use your own interpreter.

Read documentation.md for more information.

Install

To install and use this library in your application: npm install --save transactional-db

Example

Below is an extremely contrived example of how this library may be used. Similar cases to it commonly show up when inserting into 2+NF databases:

const transactional = require('transactional-db');
const {Transaction: T} = transactional;

const dbm = transactional.create('mysql', 10, {
	host: 'localhost',
	user: 'root',
	password: 'password',
	database: 'test'
});

function hash(password) { return password; }

function addUser(userName, password) {
	return T.insert('user', {
		userName,
		password
	});
}

function addAddress(street, city, state, zip) {
	return T.insert('address', {
		street,
		city,
		state,
		zip
	});
}

function linkUserAddress(userId, addressId) {
	return T.insert('user_address', {
		userId,
		addressId
	});
}

function createUser(userName, password, street, city, state, zip) {
	return do T {
		userId <- addUser(userName, hash(password))
		addressId <- addAddress(street, city, state, zip)

		do! linkUserAddress(userId, addressId)

		return `User ${userName} created with address.`
	};
}

const transaction = createUser('foo', 'bar', 'fake st', 'fake city', 'FS', 00000);

dbm
	.runTransaction(transaction)
	.fork(x => console.log(x), e => console.error(e));

The problem the above example tries to solve is inserting related records to a database, but in an atomic way. Not performing the above queries in a transaction could possibly leave the database in an inconsistent state if they do not all complete together (perhaps the database crashes after inserting the user and address, but before linking them in the join table). Running them in a transaction guarantees that this won't happen.

Because we have separated running a transaction from defining a transaction, we can guarantee two desirable things:

  1. All queries/statements run in a transactional context
  2. Two transactions can be composed together.

The only way around (1) is to not use the DSL. As long as we use it, the only things we can do are construct Transactions, compose Transactions, and run Transactions.

Note that we cannot achieve both (1) and (2) by just using the library calls alone. We could achieve either independently. To get (1) all we need to do is update our functions that interact with the database to run their queries in a transaction. But this means we have now wrapped those queries in calls to "beginTransaction" and "endTransaction", so they can no longer be composed (unless the database engine supports nested transactions, but that is semantically different anyway). To get (2) all we need to do is wrap the outermost database-interfacting-with functions in a transaction. But then someone can run any of the non-outermost functions and their queries/statements will run independently!

Note: This example is contrived and you would probably just do all the queries in one function as a transaction. This doesn't preclude the fact that there are times in a real system where you want to: Run only Transaction A, Run only Transaction B, or Run both Transaction A and Transaction B in a single large Transaction.

Credits

I based the idea on postgresql-transactional. Their software is written in Haskell and uses a Monad Transformer rather than a Free Monad.