-
Notifications
You must be signed in to change notification settings - Fork 49
Inject database name in queries dynamically #262
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JanJakes, thanks for working on this issue. If I understand correctly, this change lets the SQLite plugin mount the database with any DB_NAME automatically. The constant is still needed, but its value no longer affects accessing the database.
@JanJakes, do you think this is good to merge, or should we go with the WP_SQLITE_DB_NAME constant in the meantime? |
@sejas I'll try to finish this one now. What it misses is support for wildcards like |
bba395c
to
b8e24f4
Compare
b8e24f4
to
e1f9685
Compare
e1f9685
to
38e8249
Compare
I'm closing this in favor of #266. |
This PR replaces #262. It is a simpler solution to the same problem: When a table reference targets an information schema table, we replace it with a subquery, injecting the configured database name dynamically: ```sql -- The following query: SELECT *, t.*, t.table_schema FROM information_schema.tables t -- Will be translated to: SELECT *, t.*, t.table_schema FROM ( SELECT `TABLE_CATALOG`, IIF(`TABLE_SCHEMA` = 'information_schema', `TABLE_SCHEMA`, 'database_name') AS `TABLE_SCHEMA`, `TABLE_NAME`, ... FROM _wp_sqlite_mysql_information_schema_tables AS tables ) t ``` The same logic will be applied to table references in JOIN clauses as well. --- With the new SQLite driver, we keep running into issues with missing and incorrect database name values (#197, #203, #226, #260, #261, and other issues). Thinking through this further, I came to the conclusion that to provide maximum flexibility and portability, it would be best to provide an API in the shape of: _"Mount `my-sqlite-file.sqlite` as `my-db-name`."_ Even if we consider adding multi-database support one day, it would still be great to allow mounting additional SQLite files under dynamic database names. I don't see any downsides to doing this, except maybe that we'll have to choose some database name in some scenarios, such as in database admin tools. However, in these cases we can use a reasonable default or the file name. This is a WIP pull request demonstrating the simplest approach. For it to be merged, I only need to resolve how the existing database name values should be treated.
With the new SQLite driver, we keep running into issues with missing and incorrect database name values (#197, #203, #226, #260, #261, and other issues).
Thinking through this further, I came to the conclusion that to provide maximum flexibility and portability, it would be best to provide an API in the shape of:
"Mount
my-sqlite-file.sqlite
asmy-db-name
."Even if we consider adding multi-database support one day, it would still be great to allow mounting additional SQLite files under dynamic database names.
I don't see any downsides to doing this, except maybe that we'll have to choose some database name in some scenarios, such as in database admin tools. However, in these cases we can use a reasonable default or the file name.
This is a WIP pull request demonstrating the simplest approach. For it to be merged, I only need to resolve how the existing database name values should be treated.