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.

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

Suggestion: Add support for SQLiteStudio-Specific Meta Information #3570

fitdev opened this issue Sep 11, 2019 · 0 comments


Copy link

commented Sep 11, 2019


There is a great built-in Custom SQL Functions Editor that allows users to define extra functionality that although is not part of their SQLite database is till accessible from SQLiteStudio.

It would be great if similar approach (extra stuff that is not part of the SQLite DB is made accessible / surfaced by / used by SQLiteStudio) can be adapted to some "meta" information:

  • Table and Column descriptions. For simple databases this may not seem necessary, but for more complex databases, it is easy enough to forget certain details regarding differences between certain columns in a table for example. So, an ability to assign a table or a column a description that will be surfaced within SQLite Studio (in a tooltip for example) would be of great help.

  • When editing records, it is common for column values to come from a limited set of distinct items, like country codes for example, or education level. So, it would be useful to define such "meta-lists" and being able to bind them to desired table columns, so that when the values in those columns are edited, a drop-down would appear from which you can select a value that comes from such a list.

  • When editing a record's column whose value has a foreign key constraint, currently, SQLiteStudio already displays a dropdown with the referenced table's rows. However sometimes it has too much information, so it would be great to define a SQL Query to: 1) limit the number of rows displayed (perhaps we are not interested in all the records from the referenced table) and 2) limit the columns being displayed (not all columns may be relevant). Among other things, it would also reduce the memory and CPU usage (by displaying fewer items in a grid).

Such meta data can be saved in SQLiteStudio's preferences or, alternatively (and preferably) in another file located next to the SQLite DB. For example for a mydatabase.db database it could be a file called mydatabase.db.sls located in the same directory. Then SQLiteStudio could automatically check for presence of such files when opening databases, and thus provide database-specific UI enhancements.

SQLiteStudio version


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.