Benjamin Pannell

Another alternative would be to have connection identifiers within ORM, so creating a transaction would return a chainable object which holds some kind of transaction ID. This could then be...

I guess if we're willing to add a `commit()` method or something similar to the connection object then it would be possible to do that as well. As far as...

Okay, let's do this then. When you call `.transaction(t)` on a Model/Instance it wraps it in a transaction compatible version, it should inherit all the properties, methods etc. from the...

Something which we're missing as well is that once a connection has been pooled for a transaction, it should not be available to ORM for general requests until the transaction...

Only problem I can think of with that approach is that we will no longer have a unified cache, so objects created/retrieved/modified in one transaction will not be updated on...

Okay, I'll see what I can do about getting that working ASAP. In the mean time, I've added some early TypeScript interfaces for the module, they're missing some things like...

Unfortunately this isn't possible at the moment as the default type is hard-coded into the database drivers themselves as `INT(11) AUTO_INCREMENT` (for MySQL, the equivalent for PgSQL).

My suggestion (for the time being) would be to make changes to the [node_modules/node-sql-ddl-sync/lib/Dialects/mysql.js](https://github.com/dresende/node-sql-ddl-sync/blob/master/lib/Dialects/mysql.js#L232) file to reflect the datatype you wish to use - keep in mind that you will...

You should be able to solve this by explicitly defining an `_id` field on the model you're manipulating and by setting its type to `'text'`. You'll find that orm defines...

Just looking over your pull request, I'm not awefully happy about sniffing `_id` the way you are doing it (assuming that if it's 12/24 characters long then it's an ObjectID)....