Because pg node module is way more modern now
Fix: bug on startup and quick use

setting schema.connecting = true on initialize prevents model.stillConnecting from calling schema.connect() again. So that prevents the problem in the first place.

But the protection logic inside of connect() ensures that anyone who calls connect too many times knows about it, and doesn't run into crazy bugs (when you double-connect, your queries don't return failures - they return blank data).
config.json used to store test database info

.gitignore updated to exclude config.json, as well as generated coverage data.
Count() returns integer (fixes two failing tests)

Got these two errors:

basic-querying count should query total count:
     Uncaught AssertionError: expected '6' to equal 6
basic-querying count should query filtered count:
     Uncaught AssertionError: expected '2' to equal 2

Logic in count parses the int out, returning errors if it's either not an int, or if no data is returned. No tests cover that logic.
Force Postgres to acknowledge our UTC dates

Got this error in the tests:

  datatypes should keep types when get read data from db:
  actual:    Fri Jul 19 2013 18:04:41 GMT-0700 (PDT)
  expected:  Fri Jul 19 2013 11:04:41 GMT-0700 (PDT)

We're not roundtripping from the database properly. By attempting to save into the database in UTC, but not telling the server the value has a time zone, we save in the server's local time. From the postgres docs: "PostgreSQL never examines the content of a literal string before determining its type, and therefore will treat both of the above as timestamp without time zone." (http://www.postgresql.org/docs/9.2/static/datatype-datetime.html)

So, this change forces the database to acknowledge a timezone on the provided string. That strange .substring(1) construction removes the 'E' prefix added by escape(). We escape the result of toISOString() in case we get an object that returns malicious things from it's toISOString() method.


Regarding alternatives: before the recent change to save UTC dates, we were assuming that the local app is running in the same time zone as the postgres server. That has worked for me in the past, but this solution seems to be the better option. Of course, I don't like adding that long string to every single saved timestamp, but that's how it is in the Postgres world.
Create default test/config.json if nonexistent
order asc/desc bug fixed
Merge pull request #28 from samsaga2/master

order asc/desc bug fixed
0.0.1-7
Merge pull request #26 from scottnonnenberg/changes

A bundle of updates: more recent pg, fixing three failing tests, time zone fix, external db config...
Revert changes related to datetime
0.0.1-8
Dates have time zone in db, saved to db with tz

This preserves the necessary information to handle servers and clients running in different time zones.

And it simplifies the code, too!