pvh

Cambria, Week Two

Last week we showed you a demo of a problem. We wanted to run two different versions of a program, both operating on different data types... but with the same underlying document.

This is a tricky problem! The old code doesn't natively understand data written by the new system. The new system relies on data the old one doesn't provide. Worst, even in our little toy example there is one field where the data type changes completely, going from a Boolean type to a string.

So, if last week was a prototype of a problem then this week is a prototype of a solution.

pvh

Cambria, Week 1

Welcome, one and all to the Cambria project. Cambria is an ongoing research project here at Ink & Switch exploring how we can operate on evolving data formats in a decentralized system. We hope this work will be exciting not just for folks working on decentralized systems but could also be applicable more broadly to other distributed systems.

What's the problem?

Cambria was motivated by some problems we kept seeing in our work. The most common problem was that someone would add an array field to a document. New documents would work fine (the array would be added at document creation time) but existing documents, or documents shared by older clients, would cause Javascript runtime errors when the code would try to call Array methods on the object.

This is a very common problem in all kinds of distributed systems, and in a centralised system is mostly managed by locking down how the system works. Database schemas prevent writing

pvh

Keybase proof

I hereby claim:

• I am pvh on github.
• I am pvh (https://keybase.io/pvh) on keybase.
• I have a public key whose fingerprint is 0C58 D3A1 52EE 06E1 133B 6E0E 09F9 C3FC A774 E561

To claim this, I am signing this object:

pvh

Keybase proof

I hereby claim:

• I am pvh on github.
• I am pvh (https://keybase.io/pvh) on keybase.
• I have a public key whose fingerprint is 1D89 D8E0 2432 9132 67E4 0A9F 920A 0456 2DFF C83D

To claim this, I am signing this object:

pvh

The Node.JS language team is responsible for the success of Heroku developers building in Node. They are part of the broader “languages team”, a group of developers with similar language-specific responsibilities and shared infrastructure.

A language team is responsible for the success of their language on the platform, including varying degrees of

 * building core language-specific features such as the “build pack”,
 * working within the community to improve projects upstream to provide a better experience for Heroku users,
 * implementing support for and document Heroku product improvements for that language's community,
 * supporting existing and prospective customers through outreach and support,
 * language-specific documentation and content, and
 * marketing responsibilities such as attending and speaking at conferences.

pvh

The PHP language owner is responsible for the success of Heroku developers building in PHP. They are part of the broader “languages team”, a group of developers with similar language-specific responsibilities and shared infrastructure.

A language owner will be responsible for varying degrees of

• building core language-specific features such as the “build pack”,
• working within the community to improve projects upstream to provide a better experience for Heroku users,
• customer outreach,
• customer support,
• sales support,
• language-specific documentation and content, and
• marketing responsibilities such as attending and speaking at conferences.

pvh

• workflow

start by opening up PSQL

$ heroku pg:psql -a isis-db

what tables have we got?

\d

let's get a little more detail

\d+

pvh

A Beastiary of Badassery
-

SQLisms
--
WITH
arrays and unnest
window functions
JSON
row types

pvh

pvh$ bundle exec irb
irb(main):001:0> require 'sequel'
=> true
irb(main):002:0> DB = Sequel.connect("postgres:///")
=> #<Sequel::Postgres::Database: "postgres:///">
irb(main):003:0> DB.extension(:pg_array, :pg_row)
=> #<Sequel::Postgres::Database: "postgres:///">
irb(main):004:0> DB[:databases].select(Sequel::lit('(databases)')).all.first.values.first
=> "(foo,localhost:5432)"
irb(main):005:0> 

pvh

module Shogun
  module Once
    class OnceRecord < Sequel::Model
      Sequel.extension :pg_array
      DB.extend Sequel::Postgres::PGArray::DatabaseMethods
      unrestrict_primary_key
    end

    def self.ever(*arguments, &blk)
      OnceRecord.create(signature: signature(arguments), arguments: arguments.pg_array)