[
https://issues.apache.org/jira/browse/HIVE-21114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958796#comment-16958796
]
Ashutosh Bapat commented on HIVE-21114:
---------------------------------------
[~dkuzmenko], I don't have a Review Board account. May be you can create a pull
request which is what I am familiar with.
Anyway, here are some comments.
Changes in isValidTxnListState(), getTransactionalTableList() mostly look
refactoring changes. Are they essential to rest of the patch?
+ assert queryTxnType != TxnType.READ_ONLY || getWrittenTables(plan).isEmpty()
: String.format( + "Inferred transaction type '%s' doesn't conform to the
actual query string '%s'", + queryTxnType, queryState.getQueryString()); The
assertion may not be useful in production code. Can we please convert this into
an Exception? It will be better to add an exception in
allocate_table_write_ids() or TxnHandler#allocateTableWriteIds(), if the
request is to allocate writeId for a read-only transaction.
+ new int[]\{HiveParser.TOK_INSERT_INTO}, + new int[]\{HiveParser.TOK_INSERT,
HiveParser.TOK_TAB}) - shouldn't we also worry about TOK_UPDATE*, TOK_DELETE*
getTxnType() should also check for at least existance of UDFs, and deem the
query as non-read-only if one exists. Given the cryptic code of this function,
please add an "English" :) prologue for the function explaining the login in
the function.
Can you please add some tests for READ_ONLY txntype in TestDbTxnManager.java?
It looks like TestParseUtils should be pretty extensive, esp. since we want to
error on safer side always. That's the fear I have. We may not be able to cover
all the corner cases and possibilities. You need to add at least materialized
views, combinations of partitioned and non-partitioned tables etc.
What happens if a query involves a view and the view has UPDATE in its
definition?
> Create read-only transactions
> -----------------------------
>
> Key: HIVE-21114
> URL: https://issues.apache.org/jira/browse/HIVE-21114
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 4.0.0
> Reporter: Eugene Koifman
> Assignee: Denys Kuzmenko
> Priority: Major
> Attachments: HIVE-21114.1.patch, HIVE-21114.2.patch,
> HIVE-21114.3.patch, HIVE-21114.4.patch, HIVE-21114.5.patch,
> HIVE-21114.6.patch, HIVE-21114.7.patch
>
>
> With HIVE-21036 we have a way to indicate that a txn is read only.
> We should (at least in auto-commit mode) determine if the single stmt is a
> read and mark the txn accordingly.
> Then we can optimize {{TxnHandler.commitTxn()}} so that it doesn't do any
> checks in write_set etc.
> {{TxnHandler.commitTxn()}} already starts with {{lockTransactionRecord(stmt,
> txnid, TXN_OPEN)}} so it can read the txn type in the same SQL stmt.
> HiveOperation only has QUERY, which includes Insert and Select, so this
> requires figuring out how to determine if a query is a SELECT. By the time
> {{Driver.openTransaction();}} is called, we have already parsed the query so
> there should be a way to know if the statement only reads.
> For multi-stmt txns (once these are supported) we should allow user to
> indicate that a txn is read-only and then not allow any statements that can
> make modifications in this txn. This should be a different jira.
> cc [~ikryvenko]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
