Bug 1252333

Summary:	HBase translator - UPDATE statement requires primary key
Product:	[JBoss] JBoss Data Virtualization 6	Reporter:	Juraj Duráni <jdurani>
Component:	Teiid	Assignee:	Van Halbert <vhalbert>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Juraj Duráni <jdurani>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.2.0	CC:	atangrin, dlesage, vhalbert
Target Milestone:	ER1
Target Release:	6.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:	Hbase: 1.1.1 Phoenix: 4.5.0-HBase-1.1
Last Closed:	2016-08-24 11:45:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1252307
Bug Blocks:

Description Juraj Duráni 2015-08-11 08:09:59 UTC

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].

[1]
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).

[2]
https://github.com/teiid/teiid/blob/master/connectors/translator-hbase/src/main/java/org/teiid/translator/hbase/HBaseSQLConversionVisitor.java#L72

Comment 1 JBoss JIRA Server 2015-08-17 15:30:50 UTC

Steven Hawkins <shawkins> updated the status of jira TEIID-3621 to Resolved

Comment 2 Van Halbert 2015-08-18 14:07:59 UTC

This issue should be resolved when BZ: 1252307 is fixed.

Comment 3 Juraj Duráni 2015-08-19 05:40:34 UTC

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 12:16:35 UTC

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 18:00:54 UTC

Steven Hawkins <shawkins> updated the status of jira TEIID-3621 to Closed

Comment 6 Juraj Duráni 2016-06-15 11:34:41 UTC

Verified.

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.

[1]
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)