[ https://issues.jboss.org/browse/TEIID-4928?page=com.atlassian.jira.plugin... ] Juraj Duráni commented on TEIID-4928: ------------------------------------- There Is not exception. I received no result (not single row). With NAMEINSOURCE, I got correct result. That would make more sense to me, but still there is a lot of catches for which defining metadata manually would be better (sparse data, not all possible attributes present in current documents, renaming, moving buckets...). So custom N1QL query is a good option, but I would not discourage user from defining metadata manually. I believe you have disproved this by yourself: {quote} teiid load metadata will create metadata aotomaticly, because each of columns represent a attr in a json document {quote} If Teiid is able to do mapping *JSON attribute --> Teiid column* during metadata loading without anything else, why it is not able to map it the other way round? I.e. *Teiid column --> JSON attribute*. In fact, during metadata load e.g. JSON attribute *myAttribute* is mapped to Teiid column *myAttribute*. Why Teiid cannot do the same while mapping Teiid column *myColumn* to attribute *myColumn*? I think, that Teiid should assume, that column name and attribute name is mapped 1-to-1 in both ways by default. Only if it is not true, then user needs to define NAMEINSOURCE. This does not make sense to me. Why is table name mapped to keyspace and then there is *teiid_couchbase:NAMEDTYPEPAIR* which defines *attribute:table_name* pair? Moreover, keyspace is defined twice - first in resource-adapter definition, second in metadata. For me it would make more sense this: # Define namespace and keyspace in resource-adapter definition # For each table, define name of the attribute which determines table - e.g.: {code:sql} CREATE FOREIGN TABLE MyTable(....) OPTIONS ("teiid_couchbase:NAMEDTYPE" 'type') {code} # Now, N1QL could look like: {code:sql} SELECT ... FROM `<keyspace-from-resource-adapter>` `$cb_t1` LET ... WHERE `$cb_t1`.`<attribute-name-from-options>` = '<name-of-the-table>' {code} E.g. {code:sql} SELECT ... FROM `my_bucket` `$cb_t1` LET ... WHERE `$cb_t1`.`type` = 'MyTable' {code} For array tables, I understand information like NAMEINSOURCE is needed and it could be tricky. But I wonder, whether we need to mess up NAMEINSOURCE and fact that table is array table. Here is my suggestion (consider it really only suggestion as I did not try modeling them): # Currently, there are two information that table is an array table - it is indicated by NAMEINSOURCE and teiid_couchbase:ISARRAYTABLE option. # How about using only option ## change *teiid_couchbase:ISARRAYTABLE* to *teiid_couchbase:ARRAYTABLE* ## change type from boolean to string (with values like *nested\[\]\[\]*) ## if the option *IS NOT* present, consider table to be a regular table ## if the option *IS* present, consider table to be an array table and use value just like you use NAMEINSOURCE now What do you think? Does it make sense? -- This message was sent by Atlassian JIRA (v7.2.3#72005)