[JBoss JIRA] (TEIID-3140) Add getVDBType() method to the VDB interface
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3140?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3140:
---------------------------------------
Van that's not in scope. It will be quite sometime before all of a vdb is expressible as DDL. And there are slightly different concerns. There is the question of what is the runtime metadata (which as you point out can include details of the vdb itself) and there's the notion of the deployment artifact - which necessarily has to know what metadata repositories / ddl files / vdb details.
What Barry is trying to do is neatly categorize the VDBs, but what we're saying is that we don't make that many distinctions. We have either an xml or a zip deployment and then it's up to the details of the vdb as to how the metadata is loaded.
> Add getVDBType() method to the VDB interface
> --------------------------------------------
>
> Key: TEIID-3140
> URL: https://issues.jboss.org/browse/TEIID-3140
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
>
> Because Teiid supports mutliple VDB types, any tooling designed to interact (edit, deploy, undeploy, display etc...) with the runtime VDBs will need to be able to easilly distinguish what each VDB type is.
> Currently Teiid Designer utilizes PREVIEW and defeault VDBs with *vdb* file extensions and there are 2 types of dynamic VDBs, *xml* and *zip* files backed by DDL model metadata definitions.
> The current VDB interface currently doesn't provide a type.
> Request adding something like:
> {code}
> public enum VDBType {DEFAULT, PREVIEW, XML, DDL}
> /**
> * @return the vdb type
> */
> public VDBType getVDBType();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3140) Add getVDBType() method to the VDB interface
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3140?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3140:
------------------------------------
I think there's a bigger discussion to be had here, that the metadata that one can get by calling an admin function (rather than going thru the jdbc driver) should provide all the details of the deployed VDB in DDL form. Especially since we appear to be moving toward the TEIID DDL as the common language in tooling. And in that exported DDL, ideally, it should look like a dynamic VDB when exported. The simple benefit to this is it enables VDB's to be transitioned from between tooling and server and will be needed when Komodo is done.
> Add getVDBType() method to the VDB interface
> --------------------------------------------
>
> Key: TEIID-3140
> URL: https://issues.jboss.org/browse/TEIID-3140
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
>
> Because Teiid supports mutliple VDB types, any tooling designed to interact (edit, deploy, undeploy, display etc...) with the runtime VDBs will need to be able to easilly distinguish what each VDB type is.
> Currently Teiid Designer utilizes PREVIEW and defeault VDBs with *vdb* file extensions and there are 2 types of dynamic VDBs, *xml* and *zip* files backed by DDL model metadata definitions.
> The current VDB interface currently doesn't provide a type.
> Request adding something like:
> {code}
> public enum VDBType {DEFAULT, PREVIEW, XML, DDL}
> /**
> * @return the vdb type
> */
> public VDBType getVDBType();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3140) Add getVDBType() method to the VDB interface
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3140?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3140:
-------------------------------------
The designation is based on file type or metadata type? File type is environment specific detail whether it XML or .ZIP file, and there are many metadata types, NATIVE, DDL, .INDEX, USERDEFINED etc.
If you are looking for file designation, isXMLDeployment should be sufficient. If you are looking for metadata designation each model can be different, it needs to handled differently. I do not even think we track this currently as everything is just metadata. Increasingly most of the Dynamic VDB model metadata can be generated from multiple different metadata repos, like NATIVE and DDL. What we call that?
BTW, PREVIEW is designation that Designer gave, runtime has no knowledge of it is just a custom property, there is no XML. DEFAULT is .INDEX files.
> Add getVDBType() method to the VDB interface
> --------------------------------------------
>
> Key: TEIID-3140
> URL: https://issues.jboss.org/browse/TEIID-3140
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
>
> Because Teiid supports mutliple VDB types, any tooling designed to interact (edit, deploy, undeploy, display etc...) with the runtime VDBs will need to be able to easilly distinguish what each VDB type is.
> Currently Teiid Designer utilizes PREVIEW and defeault VDBs with *vdb* file extensions and there are 2 types of dynamic VDBs, *xml* and *zip* files backed by DDL model metadata definitions.
> The current VDB interface currently doesn't provide a type.
> Request adding something like:
> {code}
> public enum VDBType {DEFAULT, PREVIEW, XML, DDL}
> /**
> * @return the vdb type
> */
> public VDBType getVDBType();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3140) Add getVDBType() method to the VDB interface
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-3140?page=com.atlassian.jira.plugin... ]
Barry LaFond commented on TEIID-3140:
-------------------------------------
I don't think so.
Having to look inside the VDB object for specific properties, is simple enough. Currently in Designer, we're doing that to discover "preview = true". If we even expose isXmlDeployment() on the VDB, we'd still have to find yet another way/method to discover whether or not a VDB is a Dynamic VDB ZIP file (containing DDL files).
Teiid supports, out of the box, DEFAULT, PREVIEW, XML, DDL. Exposing a simple TYPE would clean up the interface and ability for tooling to quickly/easily determine what type of artifacts are deployed.
I think I understand (a little) that users can use some other metadata type (i.e. replace DDL). Maybe we add a a 5th type *USERDEFINED* to cover everthing else?
> Add getVDBType() method to the VDB interface
> --------------------------------------------
>
> Key: TEIID-3140
> URL: https://issues.jboss.org/browse/TEIID-3140
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
>
> Because Teiid supports mutliple VDB types, any tooling designed to interact (edit, deploy, undeploy, display etc...) with the runtime VDBs will need to be able to easilly distinguish what each VDB type is.
> Currently Teiid Designer utilizes PREVIEW and defeault VDBs with *vdb* file extensions and there are 2 types of dynamic VDBs, *xml* and *zip* files backed by DDL model metadata definitions.
> The current VDB interface currently doesn't provide a type.
> Request adding something like:
> {code}
> public enum VDBType {DEFAULT, PREVIEW, XML, DDL}
> /**
> * @return the vdb type
> */
> public VDBType getVDBType();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3141) Bad result of query with GROUB BY clause (underlying sybase15 datasource)
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3141?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-3141:
-------------------------------------
I think yes. I hope this will help:
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
AccessNode(1) output=[anon_grp0.gcol0 AS IntKey, anon_grp0.gcol1 AS StringKey, anon_grp0.gcol2 AS IntNum, anon_grp0.gcol3 AS StringNum, anon_grp0.gcol4 AS FloatNum, anon_grp0.gcol5 AS LongNum, anon_grp0.gcol6 AS DoubleNum, anon_grp0.gcol7 AS ByteNum, anon_grp0.gcol8 AS DateValue, anon_grp0.gcol9 AS TimeValue, anon_grp0.gcol10 AS TimestampValue, anon_grp0.gcol11 AS BooleanValue, anon_grp0.gcol12 AS CharValue, anon_grp0.gcol13 AS ShortValue, anon_grp0.gcol14 AS BigIntegerValue, anon_grp0.gcol15 AS BigDecimalValue] SELECT g_0.IntKey AS c_0, g_0.StringKey AS c_1, g_0.IntNum AS c_2, g_0.StringNum AS c_3, convert(g_0.FloatNum, float) AS c_4, g_0.LongNum AS c_5, g_0.DoubleNum AS c_6, convert(g_0.ByteNum, byte) AS c_7, convert(g_0.DateValue, date) AS c_8, convert(g_0.TimeValue, time) AS c_9, g_0.TimestampValue AS c_10, convert(g_0.BooleanValue, boolean) AS c_11, convert(g_0.CharValue, char) AS c_12, convert(g_0.ShortValue, short) AS c_13, convert(g_0.BigIntegerValue, biginteger) AS c_14, convert(g_0.BigDecimalValue, bigdecimal) AS c_15 FROM Source.SmallA AS g_0 GROUP BY g_0.IntKey, g_0.StringKey, g_0.IntNum, g_0.StringNum, convert(g_0.FloatNum, float), g_0.LongNum, g_0.DoubleNum, convert(g_0.ByteNum, byte), convert(g_0.DateValue, date), convert(g_0.TimeValue, time), g_0.TimestampValue, convert(g_0.BooleanValue, boolean), convert(g_0.CharValue, char), convert(g_0.ShortValue, short), convert(g_0.BigIntegerValue, biginteger), convert(g_0.BigDecimalValue, bigdecimal) LIMIT 100
I tried query against VDB with oracle10 and mysql55 datasource and there was no problem. Original sybase15 DB returns correct result too.
> Bad result of query with GROUB BY clause (underlying sybase15 datasource)
> -------------------------------------------------------------------------
>
> Key: TEIID-3141
> URL: https://issues.jboss.org/browse/TEIID-3141
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1
> Environment: OS: fedora20
> arch: x86_64
> java: sun 1.7
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> Description:
> There is sybase15 database with table named SmallA and table named SmallA in VDB which is mapped to sybase table (see tables definition below).
> I am trying to run query against VDB:
> SELECT
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> FROM
> BQT1.SMALLA
> GROUP BY
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> Result is table which misses some values (the other values are OK):
> FloatNum: always 0
> ByteNum: always 0
> DateValue: always 1900-01-01
> TimeValue: always 00:00:00
> BooleanValue: always 'false'
> CharValue: always empty character
> ShortValue: always 0
> BigIntegerValue: always 0
> BigDecimalValue: always 0
> After removing 'INTKEY' and 'STRINGKEY' from the query is result OK (sybase15 has indices only for these two columns).
> ///////////////////
> Table definition
> ///////////////////
> SmallA (sybase) has these columns (name:type):
> IntKey:int -> PRIMARY KEY, HAS INDEX
> StringKey:varchar -> HAS INDEX
> IntNum:int
> StringNum:varchar
> FloatNum:float
> LongNum:numeric
> DoubleNum:float
> ByteNum:real
> DateValue:datetime
> TimeValue:datetime
> TimestampValue:datetime
> BooleanValue:tinyint
> CharValue:char
> ShortValue:numeric
> BigIntegerValue:numeric
> BigDecimalValue:numeric
> ObjectValue:text
> SmallA (VDB) has these columns (name:type):
> IntKey:integer
> StringKey:string
> IntNum:integer
> StringNum:string
> FloatNum:float
> LongNum:long
> DoubleNum:double
> ByteNum:byte
> DateValue:date
> TimeValue:time
> TimestampValue:timestamp
> BooleanValue:boolean
> CharValue:char
> ShortValue:short
> BigIntegerValue:biginteger
> BigDecimalValue:bigdecimal
> ObjectValue:object
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3142) Vanilla Hive sorting issue
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3142?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3142:
---------------------------------------
Presumably this and impala issue are due to the column/server having a different collation than the expected ascii/utf. We don't yet have a great story for alternative collations. Typically we simply defer to the source sorting characteristics, such as with null first/last handling when not specified by the user query. The workarounds are to change the collation on the source or to disable order by support at the translator.
> Vanilla Hive sorting issue
> --------------------------
>
> Key: TEIID-3142
> URL: https://issues.jboss.org/browse/TEIID-3142
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> It seems that Vanilla Apache Hive 0.13 sorts in a yet another different way than what we expect and also differently from Cloudera Imapla (another Hive flavor).
> SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA order by BQT1.SmallA.StringNum
> 1: -1
> 2: -10
> 3: -11
> 4: -12
> 5: -13
> 6: -14
> 7: -15
> 8: -16
> 9: -17
> 10: -18
> 11: -19
> 12: -2
> 13: -20
> 14: -21
> 15: -22
> 16: -24
> 17: -3
> 18: -4
> 19: -5
> 20: -6
> 21: -8
> 22: -9
> 23: 0
> 24: 1
> 25: 10
> 26: 11
> 27: 12
> 28: 13
> 29: 14
> 30: 15
> 31: 16
> 32: 17
> 33: 18
> 34: 19
> 35: 2
> 36: 20
> 37: 21
> 38: 22
> 39: 23
> 40: 24
> 41: 3
> 42: 4
> 43: 5
> 44: 6
> 45: 7
> 46: 8
> 47: null
> 48: null
> 49: null
> 50: null
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3142) Vanilla Hive sorting issue
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3142?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3142:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146522
> Vanilla Hive sorting issue
> --------------------------
>
> Key: TEIID-3142
> URL: https://issues.jboss.org/browse/TEIID-3142
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> It seems that Vanilla Apache Hive 0.13 sorts in a yet another different way than what we expect and also differently from Cloudera Imapla (another Hive flavor).
> SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA order by BQT1.SmallA.StringNum
> 1: -1
> 2: -10
> 3: -11
> 4: -12
> 5: -13
> 6: -14
> 7: -15
> 8: -16
> 9: -17
> 10: -18
> 11: -19
> 12: -2
> 13: -20
> 14: -21
> 15: -22
> 16: -24
> 17: -3
> 18: -4
> 19: -5
> 20: -6
> 21: -8
> 22: -9
> 23: 0
> 24: 1
> 25: 10
> 26: 11
> 27: 12
> 28: 13
> 29: 14
> 30: 15
> 31: 16
> 32: 17
> 33: 18
> 34: 19
> 35: 2
> 36: 20
> 37: 21
> 38: 22
> 39: 23
> 40: 24
> 41: 3
> 42: 4
> 43: 5
> 44: 6
> 45: 7
> 46: 8
> 47: null
> 48: null
> 49: null
> 50: null
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (TEIID-3142) Vanilla Hive sorting issue
by Filip Nguyen (JIRA)
[ https://issues.jboss.org/browse/TEIID-3142?page=com.atlassian.jira.plugin... ]
Filip Nguyen updated TEIID-3142:
--------------------------------
Description:
It seems that Vanilla Apache Hive 0.13 sorts in a yet another different way than what we expect and also differently from Cloudera Imapla (another Hive flavor).
SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA order by BQT1.SmallA.StringNum
1: -1
2: -10
3: -11
4: -12
5: -13
6: -14
7: -15
8: -16
9: -17
10: -18
11: -19
12: -2
13: -20
14: -21
15: -22
16: -24
17: -3
18: -4
19: -5
20: -6
21: -8
22: -9
23: 0
24: 1
25: 10
26: 11
27: 12
28: 13
29: 14
30: 15
31: 16
32: 17
33: 18
34: 19
35: 2
36: 20
37: 21
38: 22
39: 23
40: 24
41: 3
42: 4
43: 5
44: 6
45: 7
46: 8
47: null
48: null
49: null
50: null
> Vanilla Hive sorting issue
> --------------------------
>
> Key: TEIID-3142
> URL: https://issues.jboss.org/browse/TEIID-3142
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> It seems that Vanilla Apache Hive 0.13 sorts in a yet another different way than what we expect and also differently from Cloudera Imapla (another Hive flavor).
> SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA order by BQT1.SmallA.StringNum
> 1: -1
> 2: -10
> 3: -11
> 4: -12
> 5: -13
> 6: -14
> 7: -15
> 8: -16
> 9: -17
> 10: -18
> 11: -19
> 12: -2
> 13: -20
> 14: -21
> 15: -22
> 16: -24
> 17: -3
> 18: -4
> 19: -5
> 20: -6
> 21: -8
> 22: -9
> 23: 0
> 24: 1
> 25: 10
> 26: 11
> 27: 12
> 28: 13
> 29: 14
> 30: 15
> 31: 16
> 32: 17
> 33: 18
> 34: 19
> 35: 2
> 36: 20
> 37: 21
> 38: 22
> 39: 23
> 40: 24
> 41: 3
> 42: 4
> 43: 5
> 44: 6
> 45: 7
> 46: 8
> 47: null
> 48: null
> 49: null
> 50: null
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months