search

sqlectron / sqlectron-gui

A simple and lightweight SQL client desktop with cross database and platform support.
https://sqlectron.github.io/
MIT License
4.57k stars 524 forks source link

Schema doesn't filter by schema #316

Closed WhyNotHugo closed 7 years ago

WhyNotHugo commented 7 years ago

I created a new connection, and set the schema to public:

2017-05-09t23 30 16 818520787-03 00

But I'm still seeing tables from all schemas (including the PG ones, which are a lot):

2017-05-09t23 30 24 202310113-03 00

BTW: Good job on the GUI, I can't believe I missed something this well polished. Except for these two bugs, this is great stuff!

santaclauze commented 7 years ago

Same issue here!

maxcnunes commented 7 years ago

@hobarrera and @santaclauze The schema field in the server information window is only the schema used for the initial connection. But you still able to access the other available schemas. If you want to filter schemas or databases listed in the sidebar then you need to define that manually in the ~/.sqlectron.json configuration (I have not included that in the server information window yet) with the filter property https://github.com/sqlectron/sqlectron-gui/blob/master/docs/app/configuration-file.md.

WhyNotHugo commented 7 years ago

Any plans to actually make the chosen schema the default later on? I think it makes sense to keep that.

Also, why dump the config in the home, instead of the standard xdg directories?

maxcnunes commented 7 years ago

We don't have plans for making the default schema the only available in the connection. But we could have like a checkbox in the server information window to make that possible. On selecting that checkbox it would automatically set that filter property.

About the xdg standard there is a separated issue for that sqlectron/sqlectron-gui/issues/327

lordjavac commented 7 years ago

How about grouping objects by schema in the lists. Then we can expand the schema we want to browse but still have access to the others. So, under "Tables" we can have "information_schema", "pg_catalog", "public", and any other applicable schemas. It think this would help declutter the lists while retaining the desired access.

maxcnunes commented 7 years ago

The trick thing about the multiple database types support is that when we need to add a new feature or changing an app behavior, you have to take in consideration all the other database clients. Some times, we need to keep the UI or even internal implementation simpler so it can have a better consistency over all databases clients. That said, I guess we didn't grouped by schemas because not all dbs have schema support. So keeping schemas in the same level with tables was the best approach to ensure UI and internal implementation consistency over all dbs. But I'm not against this feature if grouping the tables or schemas would really improve the UX. I just don't want to spend time in this feature since the current implementation is working fine for me :) If anyone else is interested to work on that I could help with any development questions.

maxcnunes commented 7 years ago

Closing it since now is possible to group schemas and the connection label for database and schemas is a bit more clear they are the initial one used in the connection. Thanks everybody for contributing!!