[jira] [Commented] (PHOENIX-6685) Change Data Capture - Populate Table / Topic Mappings
[ https://issues.apache.org/jira/browse/PHOENIX-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522575#comment-17522575 ] Bharath Vissapragada commented on PHOENIX-6685: --- I don't have any concerns. Keeping it in syscat seems logical. > Change Data Capture - Populate Table / Topic Mappings > -- > > Key: PHOENIX-6685 > URL: https://issues.apache.org/jira/browse/PHOENIX-6685 > Project: Phoenix > Issue Type: Sub-task >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 5.2.0 > > > When creating a new table with CHANGE_DETECTION_ENABLED, or when altering an > existing table to set this property to true, we should persist a mapping > between the table being enabled, and the message broker topic which will > carry its change messages. > This will allow both producers and consumers to use Phoenix metadata APIs to > figure out which topic to produce or consume from. > In the CDC prototype my colleagues and I have been working with, this has > been using a distinct system table we've manually populated. However, we may > want to consider using System.Catalog linking rows instead, to make things > more atomic. If table and topic will always be 1:1, we can also consider just > adding an optional field to SYSTEM.CATALOG that views and tables can populate. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (PHOENIX-6186) Store table metadata last modified timestamp in PTable / System.Catalog
[ https://issues.apache.org/jira/browse/PHOENIX-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214315#comment-17214315 ] Bharath Vissapragada commented on PHOENIX-6186: --- Makes sense to me. As for the new column name in syscat, my preference would be for something that is a bit more self describing like SCHEMA_LAST_MODIFICATION_TIMESTAMP / SCHEMA_LAST_MTIME/ LAST_DDL_TIMESTAMP etc. > Store table metadata last modified timestamp in PTable / System.Catalog > --- > > Key: PHOENIX-6186 > URL: https://issues.apache.org/jira/browse/PHOENIX-6186 > Project: Phoenix > Issue Type: New Feature >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 4.16.0 > > > There are many reasons why it's useful to know when a particular table's > metadata was last modified. It's helpful when solving cache coherency > problems, and also in order to interact with external schema registries which > may have multiple versions of a particular schema and require a timestamp to > resolve ambiguities. > This JIRA will add a last modified timestamp field to System.Catalog, to be > updated both when creating a table/view and also when adding or removing a > column. Changing purely internal Phoenix properties will not update the > timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5543) Implement show schemas / show tables SQL commands
[
https://issues.apache.org/jira/browse/PHOENIX-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106537#comment-17106537
]
Bharath Vissapragada commented on PHOENIX-5543:
---
Ah, there is an svn repo. Thanks. Will create a separate jira and PR.
> Implement show schemas / show tables SQL commands
> -
>
> Key: PHOENIX-5543
> URL: https://issues.apache.org/jira/browse/PHOENIX-5543
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Bharath Vissapragada
>Assignee: Bharath Vissapragada
>Priority: Minor
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-5543-4.x.v1.patch, PHOENIX-5543.master.v1.patch,
> PHOENIX-5543.master.v2.patch, PHOENIX-5543.master.v3.patch
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently users rely on {{!tables}} and {{!schemas}} commands provided by
> sqlline which pulls the information using the standard JDBC metadata calls
> like {{getTables()}} and {{getSchemas()}}.
> Most other databases (like mysql[1,2]) implement these as first class SQL
> commands that gives the user more flexibility in querying by adding necessary
> filters and looking up for table information in specific schemas. The ask
> here is to implement the following SQL commands.
> {noformat}
> SHOW SCHEMAS [LIKE '']
> SHOW TABLES [IN ] [LIKE '']
> {noformat}
> [1] https://dev.mysql.com/doc/refman/8.0/en/show-tables.html
> [2] https://dev.mysql.com/doc/refman/8.0/en/show-databases.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5543) Implement show schemas / show tables SQL commands
[
https://issues.apache.org/jira/browse/PHOENIX-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106020#comment-17106020
]
Bharath Vissapragada commented on PHOENIX-5543:
---
[~ckulkarni] Okay. Can you point me to the source code for the website? I see
that the grammar defined in phoenix.csv but I don't see the full documentation
in the phoenix git repo.
[~gjacoby] will do.
> Implement show schemas / show tables SQL commands
> -
>
> Key: PHOENIX-5543
> URL: https://issues.apache.org/jira/browse/PHOENIX-5543
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Bharath Vissapragada
>Assignee: Bharath Vissapragada
>Priority: Minor
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-5543-4.x.v1.patch, PHOENIX-5543.master.v1.patch,
> PHOENIX-5543.master.v2.patch, PHOENIX-5543.master.v3.patch
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently users rely on {{!tables}} and {{!schemas}} commands provided by
> sqlline which pulls the information using the standard JDBC metadata calls
> like {{getTables()}} and {{getSchemas()}}.
> Most other databases (like mysql[1,2]) implement these as first class SQL
> commands that gives the user more flexibility in querying by adding necessary
> filters and looking up for table information in specific schemas. The ask
> here is to implement the following SQL commands.
> {noformat}
> SHOW SCHEMAS [LIKE '']
> SHOW TABLES [IN ] [LIKE '']
> {noformat}
> [1] https://dev.mysql.com/doc/refman/8.0/en/show-tables.html
> [2] https://dev.mysql.com/doc/refman/8.0/en/show-databases.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5833) Incorrect results with LIKE operator
[
https://issues.apache.org/jira/browse/PHOENIX-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082667#comment-17082667
]
Bharath Vissapragada commented on PHOENIX-5833:
---
Couldn't repro this on older Phoenix version (4.14.3). The difference is in the
scan plan (following is when it works as expected).
{noformat}
+--+--+--+--+
| PLAN | EST_BYTES_READ
| EST_ROWS_READ | EST_INFO_TS
|
+--+--+--+--+
| CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER REPRO_BUG | null
| null | nu
|
| SERVER FILTER BY FIRST KEY ONLY AND C LIKE 'RRS\_%' | null
| null | null
|
+--+--+--+--+
{noformat}
> Incorrect results with LIKE operator
>
>
> Key: PHOENIX-5833
> URL: https://issues.apache.org/jira/browse/PHOENIX-5833
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 4.15.0
>Reporter: Bharath Vissapragada
>Priority: Critical
>
> Phoenix version: 4.15-HBase-1.5
> -- Create a test table and populate a couple of rows.
> {noformat}
> create table repro_bug(a varchar(10) not null, b varchar(10) not null, c
> varchar(10) not null constraint pk primary key(a, b, c));
> upsert into repro_bug values('abc', 'def', 'RRSQ_IMKKL');
> upsert into repro_bug values('abc', 'def', 'RRS_ZYTDT');
> select * from repro_bug;
> +--+--+-+
> | A | B | C |
> +--+--+-+
> | abc | def | RRSQ_IMKKL |
> | abc | def | RRS_ZYTDT |
> +--+--+-+
> {noformat}
> -- Query 1 - Look for rows where C has a certain prefix - Returns correct
> result
> {noformat}
> select A, B, C from REPRO_BUG where C like 'RRS\\_%';
> +--+--++
> | A | B | C |
> +--+--++
> | abc | def | RRS_ZYTDT |
> +--+--++
> {noformat}
> -- Query 2 - Look for rows where (a, b, c) > first row - Returns correct
> result
> {noformat}
> select A, B, C from REPRO_BUG where (A, B, C) > ('abc', 'def', 'RRSQ_IMKKL')
> +--+--++
> | A | B | C |
> +--+--++
> | abc | def | RRS_ZYTDT |
> +--+--++
> {noformat}
> -- Query 3 - Combine the filters from Query 1 and Query2 - Returns incorrect
> result.. Ideally it should return the same row as above.
> {noformat}
> select A, B, C from REPRO_BUG where (A, B, C) > ('abc', 'def', 'RRSQ_IMKKL')
> AND C like 'RRS\\_%';
> ++++
> | A | B | C |
> ++++
> ++++
> {noformat}
> -- Explain for the above incase someone is interested.
> {noformat}
> explain select A, B, C from REPRO_BUG where (A, B, C) > ('abc', 'def',
> 'RRSQ_IMKKL') AND C like 'RRS\\_%';
> ++-++--+
> | PLAN
>| EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> ++-++--+
> | CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN RANGE SCAN OVER REPRO_BUG
> ['abcdef'] - [*] | null| null | null |
> | SERVER FILTER BY FIRST KEY ONLY AND C LIKE 'RRS\_%'
>| null| null | null |
> ++-++--+
> 2 rows selected (0.003 seconds)
> {noformat}
> I'm trying to poke around in the code to figure out the issue but my
> understanding of Phoenix is limited at this point. So creating a bug report
> incase someone can figure this out quickly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5443) API to Generate Avro Schema of Phoenix Object
[ https://issues.apache.org/jira/browse/PHOENIX-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040539#comment-17040539 ] Bharath Vissapragada commented on PHOENIX-5443: --- Another issue with the Confluence schema registry is that it depends on the Kafka connect from Confluent's data platform and not the Apache versions. While the page[1] lists the mapping to Apache versions, there might be more work to get it working with actual apache versions of Kafka bits incase the delta between them is problematic (which isn't clear). [1] https://docs.confluent.io/current/installation/versions-interoperability.html#interoperability-versions > API to Generate Avro Schema of Phoenix Object > - > > Key: PHOENIX-5443 > URL: https://issues.apache.org/jira/browse/PHOENIX-5443 > Project: Phoenix > Issue Type: Sub-task >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > > Based on an object name (such as a table or view) and an optional tenant_id > and timestamp, we should be able to construct all the explicitly defined > columns and data types of an object. (Obviously, we can't do this for dynamic > columns.) > From these fields, we should be able to construct a schema for the object and > return it to the user. While this JIRA will focus on Avro, the output format > should be pluggable so that other implementations could output to Thrift or > Protobuf, and PHOENIX-4286 could use it to output as SQL CREATE statements. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5520) Phoenix-level HBase ReplicationEndpoint
[ https://issues.apache.org/jira/browse/PHOENIX-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015647#comment-17015647 ] Bharath Vissapragada commented on PHOENIX-5520: --- I think one solution is to prototype on branch 4.15-HBase-1.5 (since HBase-1.5 has all the dependencies) and then port it to master. Any better way? > Phoenix-level HBase ReplicationEndpoint > --- > > Key: PHOENIX-5520 > URL: https://issues.apache.org/jira/browse/PHOENIX-5520 > Project: Phoenix > Issue Type: Sub-task >Reporter: Geoffrey Jacoby >Priority: Major > > A Phoenix implementation of HBase's ReplicationEndpoint that tails the WAL > like a normal replication endpoint. However, rather than writing to HBase's > replication sink APIs (which create HBase RPCs to a remote cluster), they > should write to a new Phoenix Endpoint coprocessor (created in a separate > sub-task). > This assumes that the WAL entries have been annotated with Phoenix metadata > (tenant, logical table/view name, timestamp) using the mechanism in > PHOENIX-5435. > While many custom ReplicationEndpoints inherit from > HBaseInterClusterReplicationEndpoint and just override the filtering logic, > this will need to avoid HBaseInterClusterReplicationEndpoint (which uses > HBase RPCs and the HBase sink manager) and instead inherit from > BaseReplicationEndpoint, or even implement the ReplicationEndpoint interface > + extend AbstractService directly. This is because it has to manage its own > transport mechanism to the remote cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5520) Phoenix-level HBase ReplicationEndpoint
[ https://issues.apache.org/jira/browse/PHOENIX-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015634#comment-17015634 ] Bharath Vissapragada commented on PHOENIX-5520: --- I've started prototyping this and was attempting to annotate the entries and then realized that HBASE-22622 didn't make it to any HBase release in branch-2 line yet. There has been some recent discussion [1] about cutting branch-2.3 but I highly doubt if that is going to happen anytime soon. Current HBase version dependency of Phoenix core is 2.0.1. What is the ideal way to unblock ourselves here? Can the Phoenix master dev branch pull in SNAPSHOT dependencies of HBase rather than release versions? How does it work usually in cases like these? cc: [~apurtell] [1] https://lists.apache.org/thread.html/2a67c4515338d40c2b81006636d1be0596a40115a6149674bec6ebdc%40%3Cdev.hbase.apache.org%3E > Phoenix-level HBase ReplicationEndpoint > --- > > Key: PHOENIX-5520 > URL: https://issues.apache.org/jira/browse/PHOENIX-5520 > Project: Phoenix > Issue Type: Sub-task >Reporter: Geoffrey Jacoby >Priority: Major > > A Phoenix implementation of HBase's ReplicationEndpoint that tails the WAL > like a normal replication endpoint. However, rather than writing to HBase's > replication sink APIs (which create HBase RPCs to a remote cluster), they > should write to a new Phoenix Endpoint coprocessor (created in a separate > sub-task). > This assumes that the WAL entries have been annotated with Phoenix metadata > (tenant, logical table/view name, timestamp) using the mechanism in > PHOENIX-5435. > While many custom ReplicationEndpoints inherit from > HBaseInterClusterReplicationEndpoint and just override the filtering logic, > this will need to avoid HBaseInterClusterReplicationEndpoint (which uses > HBase RPCs and the HBase sink manager) and instead inherit from > BaseReplicationEndpoint, or even implement the ReplicationEndpoint interface > + extend AbstractService directly. This is because it has to manage its own > transport mechanism to the remote cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (PHOENIX-5543) Implement show schemas / show tables SQL commands
[
https://issues.apache.org/jira/browse/PHOENIX-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959110#comment-16959110
]
Bharath Vissapragada edited comment on PHOENIX-5543 at 10/24/19 6:02 PM:
-
[~yanxinyi] Both "show tables" and "!tables" take the same code path. Please
look at the patch [1] for more details. In fact {{!tables}} does a syscat scan
too. Here is the prepared statement that is generated when you type in
{{!tables}}
{noformat}
SELECT tenant_id TABLE_CAT,
table_schem,
table_name,
Sqltabletype(table_type) AS TABLE_TYPE,
remarks,
type_name,
self_referencing_col_name,
ref_generation,
Indexstatename(index_state) AS INDEX_STATE,
immutable_rows,
salt_buckets,
multi_tenant,
view_statement,
Sqlviewtype(view_type)AS VIEW_TYPE,
Sqlindextype(index_type) AS INDEX_TYPE,
transaction_provider IS NOT NULL AS TRANSACTIONAL,
is_namespace_mapped,
guide_posts_width,
Transactionprovidername(transaction_provider) AS TRANSACTION_PROVIDER
FROM system."catalog" "SYSTEM.TABLE"
WHERE column_name IS NULL
AND column_family IS NULL
AND table_name != ' '
AND tenant_id LIKE ?
AND tenant_id = ?
AND table_schem IS NULL
AND table_name LIKE ?
ORDER BY 4,
1,
2,
3
{noformat}
With "show tables" you can add more predicates to the above query using {{IN
LIKE }} making it even more efficient.
[1] https://github.com/apache/phoenix/pull/606/commits
was (Author: bharathv):
[~yanxinyi] Both "show tables" and "!tables" take the same code path. Please
look at the patch [1] for more details. In fact {{!tables}} does a syscat scan
too. Here is the prepared statement that is generated when you type in
{{!tables}}
{noformat}
select
TENANT_ID TABLE_CAT,TABLE_SCHEM,TABLE_NAME ,SQLTableType(TABLE_TYPE) AS
TABLE_TYPE,REMARKS
,TYPE_NAME,SELF_REFERENCING_COL_NAME,REF_GENERATION,IndexStateName(INDEX_STATE)
AS
INDEX_STATE,IMMUTABLE_ROWS,SALT_BUCKETS,MULTI_TENANT,VIEW_STATEMENT,SQLViewType(VIEW_TYPE)
AS VIEW_TYPE,SQLIndexType(INDEX_TYPE) AS INDEX_TYPE,TRANSACTION_PROVIDER IS
NOT NULL AS
TRANSACTIONAL,IS_NAMESPACE_MAPPED,GUIDE_POSTS_WIDTH,TransactionProviderName(TRANSACTION_PROVIDER)
AS TRANSACTION_PROVIDER from SYSTEM."CATALOG" "SYSTEM.TABLE" where COLUMN_NAME
is null and COLUMN_FAMILY is null and TABLE_NAME != ' ' and TENANT_ID LIKE ?
and TENANT_ID = ? and TABLE_SCHEM is null and TABLE_NAME like ? order by 4, 1,
2, 3
{noformat}
With "show tables" you can add more predicates to the above query using {{IN
LIKE }} making it even more efficient.
[1] https://github.com/apache/phoenix/pull/606/commits
> Implement show schemas / show tables SQL commands
> -
>
> Key: PHOENIX-5543
> URL: https://issues.apache.org/jira/browse/PHOENIX-5543
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Bharath Vissapragada
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently users rely on {{!tables}} and {{!schemas}} commands provided by
> sqlline which pulls the information using the standard JDBC metadata calls
> like {{getTables()}} and {{getSchemas()}}.
> Most other databases (like mysql[1,2]) implement these as first class SQL
> commands that gives the user more flexibility in querying by adding necessary
> filters and looking up for table information in specific schemas. The ask
> here is to implement the following SQL commands.
> {noformat}
> SHOW SCHEMAS [LIKE '']
> SHOW TABLES [IN ] [LIKE '']
> {noformat}
> [1] https://dev.mysql.com/doc/refman/8.0/en/show-tables.html
> [2] https://dev.mysql.com/doc/refman/8.0/en/show-databases.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5543) Implement show schemas / show tables SQL commands
[
https://issues.apache.org/jira/browse/PHOENIX-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959110#comment-16959110
]
Bharath Vissapragada commented on PHOENIX-5543:
---
[~yanxinyi] Both "show tables" and "!tables" take the same code path. Please
look at the patch [1] for more details. In fact {{!tables}} does a syscat scan
too. Here is the prepared statement that is generated when you type in
{{!tables}}
{noformat}
select
TENANT_ID TABLE_CAT,TABLE_SCHEM,TABLE_NAME ,SQLTableType(TABLE_TYPE) AS
TABLE_TYPE,REMARKS
,TYPE_NAME,SELF_REFERENCING_COL_NAME,REF_GENERATION,IndexStateName(INDEX_STATE)
AS
INDEX_STATE,IMMUTABLE_ROWS,SALT_BUCKETS,MULTI_TENANT,VIEW_STATEMENT,SQLViewType(VIEW_TYPE)
AS VIEW_TYPE,SQLIndexType(INDEX_TYPE) AS INDEX_TYPE,TRANSACTION_PROVIDER IS
NOT NULL AS
TRANSACTIONAL,IS_NAMESPACE_MAPPED,GUIDE_POSTS_WIDTH,TransactionProviderName(TRANSACTION_PROVIDER)
AS TRANSACTION_PROVIDER from SYSTEM."CATALOG" "SYSTEM.TABLE" where COLUMN_NAME
is null and COLUMN_FAMILY is null and TABLE_NAME != ' ' and TENANT_ID LIKE ?
and TENANT_ID = ? and TABLE_SCHEM is null and TABLE_NAME like ? order by 4, 1,
2, 3
{noformat}
With "show tables" you can add more predicates to the above query using {{IN
LIKE }} making it even more efficient.
[1] https://github.com/apache/phoenix/pull/606/commits
> Implement show schemas / show tables SQL commands
> -
>
> Key: PHOENIX-5543
> URL: https://issues.apache.org/jira/browse/PHOENIX-5543
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Bharath Vissapragada
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently users rely on {{!tables}} and {{!schemas}} commands provided by
> sqlline which pulls the information using the standard JDBC metadata calls
> like {{getTables()}} and {{getSchemas()}}.
> Most other databases (like mysql[1,2]) implement these as first class SQL
> commands that gives the user more flexibility in querying by adding necessary
> filters and looking up for table information in specific schemas. The ask
> here is to implement the following SQL commands.
> {noformat}
> SHOW SCHEMAS [LIKE '']
> SHOW TABLES [IN ] [LIKE '']
> {noformat}
> [1] https://dev.mysql.com/doc/refman/8.0/en/show-tables.html
> [2] https://dev.mysql.com/doc/refman/8.0/en/show-databases.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5543) Implement show schemas / show tables SQL commands
[
https://issues.apache.org/jira/browse/PHOENIX-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958453#comment-16958453
]
Bharath Vissapragada commented on PHOENIX-5543:
---
[~yanxinyi] Not sure I followed you. You mean one can craft a query against
System.catalog? Can you please expand?
> Implement show schemas / show tables SQL commands
> -
>
> Key: PHOENIX-5543
> URL: https://issues.apache.org/jira/browse/PHOENIX-5543
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Bharath Vissapragada
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently users rely on {{!tables}} and {{!schemas}} commands provided by
> sqlline which pulls the information using the standard JDBC metadata calls
> like {{getTables()}} and {{getSchemas()}}.
> Most other databases (like mysql[1,2]) implement these as first class SQL
> commands that gives the user more flexibility in querying by adding necessary
> filters and looking up for table information in specific schemas. The ask
> here is to implement the following SQL commands.
> {noformat}
> SHOW SCHEMAS [LIKE '']
> SHOW TABLES [IN ] [LIKE '']
> {noformat}
> [1] https://dev.mysql.com/doc/refman/8.0/en/show-tables.html
> [2] https://dev.mysql.com/doc/refman/8.0/en/show-databases.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5543) Implement show schemas / show tables SQL commands
[
https://issues.apache.org/jira/browse/PHOENIX-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958433#comment-16958433
]
Bharath Vissapragada commented on PHOENIX-5543:
---
I have a patch for this and I'll submit a pull request shortly. Also, can
someone please assign this to me and add me as a contributor to the project?
> Implement show schemas / show tables SQL commands
> -
>
> Key: PHOENIX-5543
> URL: https://issues.apache.org/jira/browse/PHOENIX-5543
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Bharath Vissapragada
>Priority: Minor
>
> Currently users rely on {{!tables}} and {{!schemas}} commands provided by
> sqlline which pulls the information using the standard JDBC metadata calls
> like {{getTables()}} and {{getSchemas()}}.
> Most other databases (like mysql[1,2]) implement these as first class SQL
> commands that gives the user more flexibility in querying by adding necessary
> filters and looking up for table information in specific schemas. The ask
> here is to implement the following SQL commands.
> {noformat}
> SHOW SCHEMAS [LIKE '']
> SHOW TABLES [IN ] [LIKE '']
> {noformat}
> [1] https://dev.mysql.com/doc/refman/8.0/en/show-tables.html
> [2] https://dev.mysql.com/doc/refman/8.0/en/show-databases.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
