Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[YSQL] If multiple schemas have the same table name, master UI cannot distinguish between those and only shows one table #1525

Closed
ndeodhar opened this issue Jun 10, 2019 · 3 comments
Closed

[YSQL] If multiple schemas have the same table name, master UI cannot distinguish between those and only shows one table #1525

ndeodhar opened this issue Jun 10, 2019 · 3 comments
Assignees
@d-uspenskiy
Labels
area/ysql Yugabyte SQL (YSQL) good first issue This is a good issue to start contributing!

Comments

@ndeodhar
Copy link
Contributor 

create table public.foo(a int primary key);
create schema schema1;
create table schema1.foo(a int primary key, b int);

http://127.0.0.1:7000/tables will only show one table foo.
@ndeodhar ndeodhar added good first issue This is a good issue to start contributing! area/ysql Yugabyte SQL (YSQL) labels Jun 10, 2019
@bmatican
Copy link
Contributor

Wanted to get @MarioNumber1 started on something. @ndeodhar suggested this might be a good one, but @m-iancu was mentioning that schemas might be a bit tricky to handle, as that info might not be properly exposed atm...

In the meantime, I think a similar vein worth of issue happens on the TS UI (see http://localhost:9000/tablets) if we have 2 tables with same name, it is hard to tell which tablet belong to which table, as the keyspace is not reported there.

@ndeodhar
Copy link
Contributor Author

@bmatican @m-iancu There are two parts to this:
(1) Making sure that we show all tables. In such a case, both tables should show up on master UI page but with different table IDs.
(2) Adding schema information to be able to easily identify between tables with same name but different schemas.

Right now, we don't even do (1) which is wrong. We should at least show both tables and UUID column will be different for the two. Clicking on the table will show more information like schema, tablets etc. for each.
Showing both tables should be a fairly straightforward fix in master-path-handlers.cc.

yugabyte-ci pushed a commit that referenced this issue Jun 12, 2019
@georgeklees
[#1525] [YSQL] Distinguish tables with same keyspace+name but differe…
e451efe 
…nt schema in master UI

Summary:
Addresses the problem in #1525 by using UUID
to identify each table shown in the master UI instead of using the long table name (keyspace and
table name)

Test Plan:
Use `yqlsh` to create a database called `test` and, within that, run the three SQL
commands in the Github issue. Then go to <http://localhost:7000/tables> and ensure that both tables
appear. Expected output is roughly the following: https://i.imgur.com/6nRAIp1.png

Reviewers: bogdan, mihnea, neha

Reviewed By: neha

Subscribers: yql

Differential Revision: https://phabricator.dev.yugabyte.com/D6745
yugabyte-ci pushed a commit that referenced this issue Jun 13, 2019
@georgeklees
[#1525] [YSQL] Show table UUIDs in tablet server web UI
9b80af5 
Summary:
Change TabletStatusPB to contain table UUID (whereas before it just contained table name)
and display that UUID in the tablet server web interface on port 9000. This is a follow-up to D6745.

Test Plan: Go to <http://localhost:9000/tablets> and ensure that UUIDs are shown correctly. Something like <https://phabricator.dev.yugabyte.com/F12300> should appear.

Reviewers: mihnea, bogdan, neha

Reviewed By: bogdan, neha

Subscribers: yql

Differential Revision: https://phabricator.dev.yugabyte.com/D6748
@mbautin mbautin mentioned this issue Jun 20, 2019
Closed
@ndeodhar ndeodhar assigned ndeodhar and d-uspenskiy and unassigned georgeklees and ndeodhar Aug 24, 2019
@YourTechBud
Copy link

YourTechBud commented Oct 5, 2019 •
edited
Loading

@ndeodhar displaying the schema information won't help a lot. In my use case, two schemas can have the same table with the same fields. Maybe we can show a tables oid present in the table pg_class on the ui?

d-uspenskiy added a commit that referenced this issue Nov 11, 2019
@d-uspenskiy
#1525 [YSQL] Show oid for YSQL tables in master UI
acd640f 
Summary:
Add `YSQL OID` column for table information on `http://localhost:7000/tables` master UI page.
Show OID for YSQL tables and none (empty value) for other table types.
By using `OID` it is possible to fetch extra information from YSQL systems tables.

For example schema name:
```
SELECT nsp.nspname AS schema_name, tbl.relname AS table_name
  FROM pg_namespace nsp JOIN pg_class tbl on nsp.oid = tbl.relnamespace
  WHERE tbl.oid = <TABLE_OID>;
```

Test Plan:
Manual.
- Run local cluster with `yb-ctl start`
- Create YSQL table with name `test_table_name`
- Open `http://localhost:7000/tables` URL
- Verify `YSQL OID` column value for the `test_table_name` table is equal to query result `SELECT oid FROM pg_class WHERE relname='test_table_name'`

Reviewers: kannan, mikhail, neha

Reviewed By: mikhail, neha

Subscribers: bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D7537
haikarthikssk added a commit that referenced this issue Aug 26, 2021
@haikarthikssk
[#1525][Platform] New Universe creation gets public IP assigned even …
9caa6f6 
…with flag = false

Summary:
When creating the universe,  while choosing the node and replication factor, the nodeDetailsSet is added to the configuration. The **assignPublicIP** field in the nodeDetailsSet takes the current value of the **assignPublicIP** form value.
So, later even if we change the value of **assignPublicIP** in form, it is not getting modified inside the nodeDetailsSet. This gets passed to the platform, and the platform creates nodes corresponding to the values present in the nodeDetailsSet , causing this discrepancy.

Fix:
Before submitting the form, we iterate through all of the nodeDetailsSet and assign the form value of the **assignPublicIP** to each the nodes inside nodeDetailsSet.

Test Plan:
Steps followed:
1) Choose Provider
2) toggle off the assignPublicIP
3) configure regions, nodes and replication factor.
4) Turn on the assignPublicIP
5) check , if the newly created universe has the public ip.

and reversed the initial state of the toggle and tested again.

The universe doesn't have the public IP (Actually, we can't test this scenario in portal. We need to subnet to test. The universe simple won't come up).

Reviewers: sshevchenko, andrew, mjoshi, cpadinjareveettil, ssutar

Reviewed By: cpadinjareveettil, ssutar

Subscribers: hsu, jenkins-bot, ui

Differential Revision: https://phabricator.dev.yugabyte.com/D12705
haikarthikssk added a commit that referenced this issue Aug 27, 2021
@haikarthikssk
[#1525][Platform][2.4 backport] New Universe creation gets public IP …
4e69fcc 
…assigned even with flag = false

Summary:
When creating the universe, while choosing the node and replication factor, the nodeDetailsSet is added to the configuration. The assignPublicIP field in the nodeDetailsSet takes the current value of the assignPublicIP form value.
So, later even if we change the value of assignPublicIP in form, it is not getting modified inside the nodeDetailsSet. This gets passed to the platform, and the platform creates nodes corresponding to the values present in the nodeDetailsSet , causing this discrepancy.

Fix:
Before submitting the form, we iterate through all of the nodeDetailsSet and assign the form value of the assignPublicIP to each the nodes inside nodeDetailsSet.

Test Plan:
Steps followed:

Choose Provider
toggle off the assignPublicIP
configure regions, nodes and replication factor.
Turn on the assignPublicIP
check , if the newly created universe has the public ip.
and reversed the initial state of the toggle and tested again.

The universe doesn't have the public IP (Actually, we can't test this scenario in portal. We need to subnet to test. The universe simple won't come up).

Reviewers: ssutar, mjoshi, cpadinjareveettil

Reviewed By: cpadinjareveettil

Subscribers: jenkins-bot, ui

Differential Revision: https://phabricator.dev.yugabyte.com/D12764
haikarthikssk added a commit that referenced this issue Aug 27, 2021
@haikarthikssk
[#1525][Platform][2.6 backport] New Universe creation gets public IP …
22df8ce 
…assigned even with flag = false

Summary:
When creating the universe, while choosing the node and replication factor, the nodeDetailsSet is added to the configuration. The assignPublicIP field in the nodeDetailsSet takes the current value of the assignPublicIP form value.
So, later even if we change the value of assignPublicIP in form, it is not getting modified inside the nodeDetailsSet. This gets passed to the platform, and the platform creates nodes corresponding to the values present in the nodeDetailsSet , causing this discrepancy.

Fix:
Before submitting the form, we iterate through all of the nodeDetailsSet and assign the form value of the assignPublicIP to each the nodes inside nodeDetailsSet.

Test Plan:
teps followed:

Choose Provider
toggle off the assignPublicIP
configure regions, nodes and replication factor.
Turn on the assignPublicIP
check , if the newly created universe has the public ip.
and reversed the initial state of the toggle and tested again.

The universe doesn't have the public IP (Actually, we can't test this scenario in portal. We need to subnet to test. The universe simple won't come up).

Reviewers: mjoshi, cpadinjareveettil, ssutar

Reviewed By: cpadinjareveettil, ssutar

Subscribers: jenkins-bot, ui

Differential Revision: https://phabricator.dev.yugabyte.com/D12765
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@d-uspenskiy d-uspenskiy

Labels
area/ysql Yugabyte SQL (YSQL) good first issue This is a good issue to start contributing!
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@bmatican @georgeklees @ndeodhar @YourTechBud @d-uspenskiy