Bug 1252333 - HBase translator - UPDATE statement requires primary key
HBase translator - UPDATE statement requires primary key
Product: JBoss Data Virtualization 6
Classification: JBoss
Component: Teiid (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ER1
: 6.3.0
Assigned To: Van Halbert
Juraj Duráni
Depends On: 1252307
  Show dependency treegraph
Reported: 2015-08-11 04:09 EDT by Juraj Duráni
Modified: 2016-08-24 07:45 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Hbase: 1.1.1 Phoenix: 4.5.0-HBase-1.1
Last Closed: 2016-08-24 07:45:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker TEIID-3621 Major Closed HBase translator - UPDATE statement requires primary key 2016-06-15 07:34 EDT

  None (edit)
Description Juraj Duráni 2015-08-11 04:09:59 EDT
The HBase translator requires table to have a primary key defined. Is the PK really needed? If the table has no PK defined, then all columns are PK. E.g. query UPDATE hbase.SmallA SET StringNum = '555' WHERE hbase.SmallA.StringNum IS NULL is translated as UPSERT INTO smalla (stringnum, intkey) SELECT '555', smalla.intkey FROM smalla WHERE smalla.stringnum IS NULL (intkey is PK). Teiid can simply add all columns (except those defined in 'SET').

Yes, I know that HBase requires the PK to be defined, but what happen if a user decide to change PK in VDB [1]? It could be a problem whether PK is in VDB defined or not.

I suggest to add a hbase-translator-specific execution property which define PK in the source table and remove AssertionError [2].

HBase table: create table mytable(id integer primary key, nickname varchar(1))

Teiid table: create table mytable(id integer, username varchar(1) primary key)

Both, id and username, are valid PK (artificial/natural).

Comment 1 JBoss JIRA Server 2015-08-17 11:30:50 EDT
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-3621 to Resolved
Comment 2 Van Halbert 2015-08-18 10:07:59 EDT
This issue should be resolved when BZ: 1252307 is fixed.
Comment 3 Juraj Duráni 2015-08-19 01:40:34 EDT
Why does this bug depends on 1252307? TEIID-3619 (1252307) is matter of Phoenix architecture. This bug is a regular bug in the Teiid.
Furthermore, the property "phoenix.connection.autoCommit" will neither resolve this issue nor help in fixing.
Comment 4 Van Halbert 2015-08-19 08:16:35 EDT
I'll restate.   The Update related fixes (update,insert,delete) are being targeted for for the 8.12.   And since this is tech preview, it was agreed that these didn't need to be back ported.
Comment 5 JBoss JIRA Server 2016-01-26 13:00:54 EST
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-3621 to Closed
Comment 6 Juraj Duráni 2016-06-15 07:34:41 EDT

Teiid does not throw AssertionError anymore. Instead Phoenix exception is thrown which is more appropriate and expected [1].

Project documentation has been updated. I have logged BZ1346808 to add warning also into product documentation.

Caused by: java.sql.SQLException: ERROR 218 (22018): Constraint violatioin. SMALLA.INTKEY may not be null
	at org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:395)

Note You need to log in before you can comment on or make changes to this bug.