jetty.project
                                
                                 jetty.project copied to clipboard
                                
                                    jetty.project copied to clipboard
                            
                            
                            
                        Use getSchemaTableName also in the create table statement
When all other sql statements are built, this method is used for including the schema name in front of the table name (if specified). So to make it more consistent, it would be better to also create the table in the specified schema.
PS: Please indulge me for not opening an issue, as i think this optimization is pretty trivial and need no big discussion.
Signed-off-by: Michael Weigmann [email protected]
I think CI failure was an overload of the CI machine. Re-running...
@mwgmnn so prior to this change, is it true that the table would not have been found as part of the schema, and so would have been recreated, but outside the schema? Does this change mean that a table that was existing outside of the schema will now be recreated within the schema? Is there likely to be any data loss because of that?
Hi @janbartel, it depends on what the default schema for the user is and what schema name is set. In oracle for example the table is created in the users own schema (same name as user), when you don't specify another schema name, while in mssqlserver the table is created by default in schema 'dbo'. So the metaData.getTables call in prepareTables would find the table only in oracle when you specify the user as schema name (which might be relatively common besides from not using a schema name at all).
If the table already exists, the driver/db throws an sql exception. So i think others should have run into this problem too, when they use schema names that differ from the default schema. If on the other side the jdbc session storage was already functioning nothing changes, as the check for the existing table isn't modified by this merge request. The table is already inside the right schema and a data loss shouldn't occur. The change only opens the possibility to use another schema than the default one in new installations.
@mwgmnn so IIUC: prior to this PR, if a user had specified a schema name that was different to the default schema for the database, then the table would have been created in the default schema. Thus all subsequent jdbc interactions would fail, because we use the fully qualified table name for those?
@janbartel Yes, that's correct. And to be more precise: the default schema is not fix for the database, it can be set for the user specifically, at least in MSSQLServer, or in Oracle you can execute something like ALTER SESSION SET CURRENT_SCHEMA = xyz;. So it is also very dbms specific.