What would I need to do in order to emulate an INSERT or UPDATE in Phoenix, as
opposed to an UPSERT?
Suppose I had a TRANSACTIONAL table. To do an INSERT, I then:
1. Start a transaction
2. SELECT the relevant rows, and throw an error if the SELECT is non-empty
3. UPSERT
4. Commit th
If the table is transactional, you are guaranteed that if there are
overlapping transactions that try to commit the same row one will succeed
and the others will fail with an exception. There is also an additional
cost to doing conflict detection at commit time.
On Thu, Jul 28, 2016 at 8:18 AM, H
James,
Your logic looks correct, assuming that you have the complete row keys in
your SELECT statement. FYI, the transaction will start automatically at
(2). You can optimize this slightly by just doing a COUNT(*) instead of
returning the rows back to the client. For the UPDATE case, you'd throw if
Thanks.
What do you mean when you say the transaction starts automatically at (2)? Do
you mean that you don't need to start a transaction explicitly?
If that's right, does that mean that you need to commit even after you've only
done read operations, so that Phoenix knows to close the transacti
Yes, you don't have to start a transaction explicitly. You don't need to
commit after you have done only reads. Transactions timeout depending
on the data.tx.timeout attribute (see
http://phoenix.apache.org/transactions.html).
On Thu, Jul 28, 2016 at 11:06 PM, Heather, James (ELS) <
james.heat...@
James - you do have to be a bit careful with selects over transactional
tables. If you have a connection that's only doing selects (over
transactional tables) and you want each of them to run in a new
transaction, you can call conn.setAutoCommit(true) which will cause each
select to start a new tra
