4 ms·

Not really related to TFA, but I had a look at the python driver documentation and I was very surprised by this statement [0]: > Limitations > Transactions ar

Not really related to TFA, but I had a look at the python driver documentation and I was very surprised by this statement [0]: > Limitations > Transactions are not supported Is there something I am badly misreading? How come is a so fundamental feature not supported? Maybe it is just a limitation in the python driver? [0] https://github.com/rqlite/pyrqlite#limitations= https://github.com/rqlite/pyrqlite#limitations=

otoolep 4y ago
No, it's due to rqlite. rqlite does support a form of transactions -- you can send a set of SQLite statements, and either all will be successful, or none will be. You can even send a BEGIN statement, and a SQLite transaction will be opened (and you can COMMIT later). However, due to the nature of Raft, restarting the cluster in the middle of an open transaction will not clear the transaction -- and most folks probably don't expect this. That's why I need to think more before advocating use of traditional transactions with rqlite -- distributed transaction functionality is easy to get wrong, so requires careful thought. You can use SQLite transactions, but you must be careful. That's why drivers don't tend to support it yet. https://github.com/rqlite/rqlite/blob/master/DOC/DATA_API.md#transactions https://github.com/rqlite/rqlite/blob/master/DOC/DATA_API.md...
- ______-_-______ 4y ago
  Taken from the readme: > the behavior of a cluster if it fails while such a manually-controlled transaction is not yet defined Do you envision manually-controlled transactions working seamlessly one day? If not, have you thought about what guarantees are feasible/you hope to provide?
  - otoolep 4y ago
    Yes, I have a design in mind, but it's a fair amount of work. It will require a new API too -- and API that allows clients to explicitly create a new connection, create a transaction on it, and close that transaction when finished.
    - pkaye 4y ago
      I there a go client other than gorqlite which doesn't seem to actively maintained.
- stavros 4y ago
  Would it be a better compromise to support transactions as long as they were sent as a single block?
  - otoolep 4y ago
    Not sure if I follow you, but that's exactly what rqlite does support. https://github.com/rqlite/rqlite/blob/master/DOC/BULK.md https://github.com/rqlite/rqlite/blob/master/DOC/BULK.md
    - stavros 4y ago
      Sorry, I meant from a marketing perspective, saying "transactions are only supported in batch mode" rather than saying they aren't supported.
zeckalpha 4y ago
MySQL didn’t have transactions for years! A transaction layer can be implemented by adding a transaction table, a transaction column to each other table, and joining the two in your queries. where table.transaction_id = transaction.id and transaction.committed = true You would begin a transaction by inserting a new row and then updating it to committed when done. With some metaprogramming you may be able to do this all transparently.
- srcreigh 4y ago
  How would this provide read / write isolation? Or rollback in case of failure(power outage)?
  - zeckalpha 4y ago
    As an exercise for the reader. :) Both are possible and have been done before.

otoolep 4y ago

No, it's due to rqlite. rqlite does support a form of transactions -- you can send a set of SQLite statements, and either all will be successful, or none will be. You can even send a BEGIN statement, and a SQLite transaction will be opened (and you can COMMIT later). However, due to the nature of Raft, restarting the cluster in the middle of an open transaction will not clear the transaction -- and most folks probably don't expect this. That's why I need to think more before advocating use of traditional transactions with rqlite -- distributed transaction functionality is easy to get wrong, so requires careful thought. You can use SQLite transactions, but you must be careful. That's why drivers don't tend to support it yet. https://github.com/rqlite/rqlite/blob/master/DOC/DATA_API.md#transactions https://github.com/rqlite/rqlite/blob/master/DOC/DATA_API.md...

______-_-______ 4y ago
Taken from the readme: > the behavior of a cluster if it fails while such a manually-controlled transaction is not yet defined Do you envision manually-controlled transactions working seamlessly one day? If not, have you thought about what guarantees are feasible/you hope to provide?
- otoolep 4y ago
  Yes, I have a design in mind, but it's a fair amount of work. It will require a new API too -- and API that allows clients to explicitly create a new connection, create a transaction on it, and close that transaction when finished.
  - pkaye 4y ago
    I there a go client other than gorqlite which doesn't seem to actively maintained.
stavros 4y ago
Would it be a better compromise to support transactions as long as they were sent as a single block?
- otoolep 4y ago
  Not sure if I follow you, but that's exactly what rqlite does support. https://github.com/rqlite/rqlite/blob/master/DOC/BULK.md https://github.com/rqlite/rqlite/blob/master/DOC/BULK.md
  - stavros 4y ago
    Sorry, I meant from a marketing perspective, saying "transactions are only supported in batch mode" rather than saying they aren't supported.

zeckalpha 4y ago

MySQL didn’t have transactions for years! A transaction layer can be implemented by adding a transaction table, a transaction column to each other table, and joining the two in your queries. where table.transaction_id = transaction.id and transaction.committed = true You would begin a transaction by inserting a new row and then updating it to committed when done. With some metaprogramming you may be able to do this all transparently.

srcreigh 4y ago
How would this provide read / write isolation? Or rollback in case of failure(power outage)?
- zeckalpha 4y ago
  As an exercise for the reader. :) Both are possible and have been done before.