ducky/subscriptions

Paddy 2015-09-30 Parent:f1a22fc2321d

15:aab6ba5ae392 Go to Latest

ducky/subscriptions/postgres.go

Log Postgres test failures more verbosely, fix SubscriptionChange.IsEmpty. SubscriptionChange.IsEmpty() would return false even if no actual database operations are going to be performed. This is because we allow information we _don't_ store in the database (Stripe source, Stripe email) to be specified in a SubscriptionChange object, just so we can easily access them. Then we use the Stripe API to store them in Stripe's databases, and turn them into data _we_ store in our database. Think of them as pre-processed values that are never stored raw. The problem is, we were treating these properties the same as the properties we actually stored in the database, and (worse) were running database tests for combinations of these properties, which was causing test failures because we were trying to update no columns in the database. Whoops. I removed these properties from the IsEmpty helper, and removed them from the code that generates the SubscriptionChange permutations for testing. This allows tests to pass, but also stays closer to what the system was designed to do. In tracking down this bug, I discovered that the logging we had for errors when running Postgres tests was inadequate, so I updated the logs when that failure occurs while testing Postgres to help surface future failures faster.

History
1 package subscriptions
3 import (
4 "database/sql"
5 )
7 // NewPostgres returns a usable Postgres instance, if and only
8 // if error is nil. If error is not nil, the returned Postgres
9 // instance should not be used.
10 func NewPostgres(conn string) (Postgres, error) {
11 db, err := sql.Open("postgres", conn)
12 if err != nil {
13 return Postgres{}, err
14 }
15 return Postgres{db}, nil
16 }
18 // Postgres represents a thin wrapper around *sql.DB, so we can
19 // inherit its methods but also define our own (so we can fulfill
20 // our subscriptionStore interface on Postgres). Note that the
21 // value of a Postgres variable contains a _pointer_ to an sql.DB
22 // pool of connections, so it's not necessary to use the address of
23 // the Postgres variable itself (though there shouldn't be any harm
24 // in doing so).
25 type Postgres struct {
26 *sql.DB
27 }