[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3296:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1207222|https://bugzilla.redhat.com/show_bug.cgi?id=1207222] from NEW to MODIFIED
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 8.10, 8.7.2, 8.7.1.6_2
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3461) Error executing statement with lookup function - Sybase 15 ASE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3461?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3461:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1217304|https://bugzilla.redhat.com/show_bug.cgi?id=1217304] from NEW to ASSIGNED
> Error executing statement with lookup function - Sybase 15 ASE
> --------------------------------------------------------------
>
> Key: TEIID-3461
> URL: https://issues.jboss.org/browse/TEIID-3461
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.11
>
> Attachments: server.log
>
>
> Query [1] ends with an exception [2] (root sybase exception [3]). Source specific command [4]. Server log - see attachment.
> [1] SELECT BQT1.SmallA.IntKey, BQT1.MediumB.IntKey FROM BQT1.SmallA FULL OUTER JOIN BQT1.MediumB ON BQT1.SmallA.IntKey = lookup('BQT1.MediumB', 'IntKey', 'StringKey', BQT1.MediumB.StringKey) WHERE BQT1.MediumB.IntKey < 100 ORDER BY BQT1.MediumB.IntKey
> [2] org.teiid.jdbc.TeiidSQLException: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 Source: 7738 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511, 512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 625, 626, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656, 657, 658, 659, 660, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 680, 681, 682, 683, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696, 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708, 709, 710, 711, 712, 713, 714, 715, 716, 717, 718, 719, 720, 721, 722, 723, 724, 725, 726, 727, 728, 729, 730, 731, 732, 733, 734, 735, 736, 737, 738, 739, 740, 741, 742, 743, 744, 745, 746, 747, 748, 749, 750, 751, 752, 753, 754, 755, 756, 757, 758, 759, 760, 761, 762, 763, 764, 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787, 788, 789, 790, 791, 792, 793, 794, 795, 796, 797, 798, 799,
> 800, 801, 802, 803, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819, 820, 821, 822, 823, 824, 825, 826, 827, 828, 829, 830, 831, 832, 833, 834, 835, 836, 837, 838, 839, 840, 841, 842, 843, 844, 845, 846, 847, 848, 849, 850, 851, 852, 853, 854, 855, 856, 857, 858, 859, 860, 861, 862, 863, 864, 865, 866, 867, 868, 869, 870, 871, 872, 873, 874, 875, 876, 877, 878, 879, 880, 881, 882, 883, 884, 885, 886, 887, 888, 889, 890, 891, 892, 893, 894, 895, 896, 897, 898, 899, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 910, 911, 912, 913, 914, 915, 916, 917, 918, 919, 920, 921, 922, 923, 924, 925, 926, 927, 928, 929, 930, 931, 932, 933, 934, 935, 936, 937, 938, 939, 940, 941, 942, 943, 944, 945, 946, 947, 948, 949, 950, 951, 952, 953, 954, 955, 956, 957, 958, 959, 960, 961, 962, 963, 964, 965, 966, 967, 968, 969, 970, 971, 972, 973, 974, 975, 976, 977, 978, 979, 980, 981, 982, 983, 984, 985, 986, 987, 988, 989, 990, 991, 992, 993, 994, 995, 996, 997, 998, 999] SQL: SELECT g_0.IntKey AS c_0 FROM bqt2.dbo.SmallA g_0 WHERE g_0.IntKey IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) OR g_0.IntKey IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) OR g_0.IntKey IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) OR g_0.IntKey IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ORDER BY c_0
> [3] java.sql.SQLException: Remote com.sybase.jdbc4.jdbc.SybSQLException: Message empty.
> [4] [org.teiid.CONNECTOR] (Worker7_QueryProcessorQueue650) Source-specific command: SELECT g_0.StringKey, g_0.IntKey FROM bqt2.dbo.MediumB g_0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3345) NPE while accessing VDB via OData access
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3345?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3345:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1194292|https://bugzilla.redhat.com/show_bug.cgi?id=1194292] from NEW to ASSIGNED
> NPE while accessing VDB via OData access
> ----------------------------------------
>
> Key: TEIID-3345
> URL: https://issues.jboss.org/browse/TEIID-3345
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: Alpha1
> Fix For: 8.11
>
>
> If wrong odata URL is provided, an internal error is displayed:
> URL: http://localhost:8080/odata/
> Exception: org.teiid.core.TeiidRuntimeException: TEIID16008 VDB name not defined on the URL. The url format is http://{host}:{port}/odata/{vdb-name}[.{vdb-version}]/...
> org.teiid.odata.TeiidProducerProvider.getContext(TeiidProducerProvider.java:88)
> org.teiid.odata.TeiidProducerProvider.getContext(TeiidProducerProvider.java:47)
> ....
> This behavior is quite expected.
> URL: http://localhost:8080/odata
> Exception: java.lang.NullPointerException
> org.teiid.odata.TeiidProducerProvider.getContext(TeiidProducerProvider.java:80)
> org.teiid.odata.TeiidProducerProvider.getContext(TeiidProducerProvider.java:47)
> ...
> I expect that teiid should return similar exception
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3448) User query should be terminated when TEIID30001
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3448?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3448:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1213677|https://bugzilla.redhat.com/show_bug.cgi?id=1213677] from NEW to CLOSED
> User query should be terminated when TEIID30001
> -----------------------------------------------
>
> Key: TEIID-3448
> URL: https://issues.jboss.org/browse/TEIID-3448
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Environment: JDV6.0, 6.1
> Reporter: Hisanobu Okuda
> Assignee: Steven Hawkins
> Attachments: buffertest.vdb, create_db.sql, jdv_client.zip, standalone.xml, testdata_a.csv.gz, testdata_b.csv.gz
>
>
> Even if I get the following error when I access a mat view for the first time just after starting JDV:-
> {code}
> 12:45:46,404 ERROR [org.teiid.BUFFER_MGR] (BufferManager Cleaner) TEIID30001 Max block number exceeded by 1 0. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller.
> {code}
> the result for the query returns sucessfully.
> However, the 2nd access to the mat view gives an error at client side:-
> {code}
> org.teiid.jdbc.TeiidSQLException: Batch not found in storage 0
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:668)
> {code}
> And server side:-
> {code}
> 12:52:50,961 ERROR [org.teiid.PROCESSOR] (Worker3_QueryProcessorQueue6) TEIID30019 Unexpected exception for request LdGNTpFDRwjr.0: java.lang.AssertionError: Batch not found in storage 0
> at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.getBatch(BufferManagerImpl.java:306) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.common.buffer.SPage.getValues(SPage.java:237) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.common.buffer.TupleBrowser.nextTuple(TupleBrowser.java:223) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.tempdata.TempTable$QueryTupleSource.nextTuple(TempTable.java:192) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:110) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:369) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.LimitNode.nextBatchDirect(LimitNode.java:102) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:89) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.GroupingNode.groupPhase(GroupingNode.java:405) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:336) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:159) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:141) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:444) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:326) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.1.redhat-8.jar:8.7.1.redhat-8]
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
> I do not think I follow you on this one. there is no execute-query on admin?
It's not exposed on the AdminApi interface, but there is an execute-query operation.
> I am failing to see is, how this metadata access is different from current SYS tables. (I know content is different, I am asking about the interface)
The content is entirely different. The sys tables are derived from the loaded metadata. There would be no loaded metadata for translator metadata procedures - it's just a minimal re-exposure of their metadata facilities. I'm proposing very little magic or abstraction - the import process will still need knowledge of a flow (ask for catalog and table types first, then schemas, then tables/procedures). The interface is entirely different as well. These would be source procedures vs. system tables.
> I do like you Admin suggestion without vdb.There may be merits for both, but if this is primarily for tooling, I am somehow blocked in my thinking past the Admin
This doesn't fit neatly with any existing concept as you're not really dealing with a proper vdb nor the Teiid metadata. Most generically an admin method could be:
List<List<?>> getMetadata('metadata method', List of args, 'translator name', Map of translator properties, 'jndi name'). However if we are going that far, then it may be just as well to not route this logic through the translator at all and just introduce some light weight remoting logic such that the Designer can get at the metadata facilities of the relevant connection directly.
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3429:
-------------------------------------
>Any interface yes. Even the execute-query admin operation.
I do not think I follow you on this one. there is no execute-query on admin?
> do want to see something different about this flow?
Yes, was re-iterating for implementation purpose.
I see that, you are looking at this as way to expose the these methods on generically on a translator, which is not related to metadata load process at all. More like exposing system tables for sources, but through procedures. They will serve the data from directly from source, rather then already loaded metadata for that model. I am failing to see is, how this metadata access is different from current SYS tables. (I know content is different, I am asking about the interface)
I am thinking more of flow to build up the query to load metadata for model, thus I see it as exposing as Admin method. I do like you Admin suggestion without vdb.There may be merits for both, but if this is primarily for tooling, I am somehow blocked in my thinking past the Admin :(
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
> I guess, you are thinking to expose as procedures, then they can be called using the jdbc interface.
Any interface yes. Even the execute-query admin operation.
> My concern there is there is two ways we providing the exposure to the source metadata, one through "getSchema" method on admin API and through JDBC. It would be nice to provide single way.
A couple of things. First is that DDL is not appropriate for this. As mentioned in the description it doesn't make sense to send back partial DDL. The next is that it seems clearer to expose the source view of metadata rather than the Teiid view - as that is more idiomatic to the import process. So these procedures would return values that represent source structure - source table name, schema, and catalog for jdbc rather than just a name in source. Lastly the admin logic is somewhat of a one off - there's a lot more overhead in adding new handlers, support (or not) for embedded, etc. The only benefit I can see from using the admin would be to deploy the vdb with connection type none such that it's not generally accessible. Alternatively over admin you could have something that takes a translator name, a jndi name, translator properties, etc. to not require a vdb.
> Yes, without that tools like designer will not have access to raw metadata. Also this needs to be on empty (vdb with metadata not loaded based on some flag, except for methods you mentioned above) vdb, which is pre-cursor to when you are ready to do the import with full "importer" properties that can get the actual metadata.
Just to make sure I'm not missing something, are you simply reiterating or do want to see something different about this flow?
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3429:
-------------------------------------
>Are you thinking something special, such as specific exposure on the adminapi?
I guess, you are thinking to expose as procedures, then they can be called using the jdbc interface. My concern there is there is two ways we providing the exposure to the source metadata, one through "getSchema" method on admin API and through JDBC. It would be nice to provide single way.
Yes, without that tools like designer will not have access to raw metadata. Also this needs to be on empty (vdb with metadata not loaded based on some flag, except for methods you mentioned above) vdb, which is pre-cursor to when you are ready to do the import with full "importer" properties that can get the actual metadata.
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 5 months