Custom primary key (not keys, just singular) should no longer be a problem for models when using any of the data retrievals with just a number or through associations. Closes #694
Forgot to add special whereCondition fix for postgres as well.
Postgres was complaining about varchar != integer. My instance didn't do this though. Simple fix.
added hipchat
Updated pg and node-validator dependencies.
Merge pull request #808 from durango/depen-update

Updated pg and node-validator dependencies.
Merged master, fixed Postgres connector, and fixed potential null problem with associations.
Fixed up postgres client + query.run
Reverted back to my original postgres pooling mechanism.
We no longer care about isConnecting status when we're using a pool (to fast).
Cleaned up postgres/query a little bit.
Cleaned up postgres/connector-manager
Attempt to fix MySQL tests.
Merge branch 'association-key' of https://github.com/durango/sequelize into durango-association-key
check mysql 5.6 as well
Revert "check mysql 5.6 as well"

This reverts commit 77e86a11747af91a8f822499ffe8ae67d16c2cf7.
just a small note
enforce omitNull to be false
Fixed up one off connection clients for Sequelize (if client is already defined simply callback rather than connecting again).
Merge pull request #771 from durango/association-key

Custom primary key (not keys, just singular) should no longer be a problem for models when using any of the data retrievals with just a number or through associations. Closes #694