Support Transaction Rollback about db

[xiam]

Transactions were not supported because the initial approach of upper.io/db was being fully compatible with major SQL and NoSQL databases. MongoDB lacked supports for transactions and that was holding us back. Even now, support for transaction-like operatios in MongoDB still feels like black magic.

But after all, MongoDB should not be an obstacle. We'll still support CRUD compatibility across all adapters but we'll also introduce some database-specific features, like transactions.

Support for transactions is currently on the experimental branch but we need to document it and test it a bit more in order to release it. I think we'll be able to release it next week.

[maxhawkins]

Do you have a pattern for dealing with unsupported behavior in drivers? Returning an error would make sense, but I'm not sure if there's another way.

Feature parity on -every- database seems hard to accomplish. For instance, on the AppEngine Data Store counting is a nontrivial operation and requires a separate MapReduce step.

On Thu, Jun 19, 2014 at 8:19 AM, Carlos Nieto [email protected]
wrote:

Transactions were not supported because the initial approach of upper.io/db was being fully compatible with major SQL and NoSQL databases. MongoDB lacked supports for transactions and that was holding us back. Even now, support for transaction-like operatios in MongoDB still feels like black magic.
But after all, MongoDB should not be an obstacle. We'll still support CRUD compatibility across all adapters but we'll also introduce some database-specific features, like transactions.

Support for transactions is currently on the experimental branch but we need to document it and test it a bit more in order to release it. I think we'll be able to release it next week.

Reply to this email directly or view it on GitHub:
#23 (comment)

[xiam]

I think returning error is a good and easy way of handling this situation, this way if we could eventually use transactions on mongodb we'll just have to remove the error and proceed.

For example, If you try to use db.Transaction() on the mongo adapter a newly introduced db.ErrUnsupported is returned (should it be db.ErrNotSupported or db.ErrUnsupportedOperation?).

[maxhawkins]

Cool. ErrUnsupported sounds like the right way to go.

I'm considering writing an appengine data store driver and I'll use that error for the Count method.

On Thu, Jun 19, 2014 at 9:31 AM, Carlos Nieto [email protected]
wrote:

I think returning error is a good and easy way of handling this situation, this way if we could eventually use transactions on mongodb we'll just have to remove the error and proceed.
For example, If you try to use db.Transaction() on the mongo adapter a newly introduced db.ErrUnsupported [is returned][1](should it be db.ErrNotSupported or db.ErrUnsupportedOperation?).

[1]: https://github.com/upper/db/blob/experimental/mongo/database.go#L86

Reply to this email directly or view it on GitHub:
#23 (comment)

[xiam]

Test for PostgreSQL transactions: 2cec612#diff-e4728f444b24839e3f80adf3829bcba9 on experimental.

[maxhawkins]

Working for me. Thanks.