Re: Question: Table scheme 'default'
> I think this case should fail with error like "only cache created tables > can be removed with drop table. ", not with "scheme not found." > SQL-engine is supposed to accept and understand values it returns itself. Agree. Feel free to contribute a fix. My expectation here is that it will not be a trivial one. пт, 31 янв. 2020 г. в 18:22, Vladimir Steshin : > > //Got a connectionConnection conn = ...; > > //execute() - is just a helper function. Creates prepared statement, pass > params... > //Get all the tables > List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from > SYS.TABLES"); > > for( List row : lst ){ > String schemaName = (String)row.get(0); > String tableName = (String)row.get(1); > > //Shows: "schema: default, table: PERSON" > System.out.println("schema: " + schemName + ", table: " + > tableName)); > > //Fails with with: java.sql.SQLException: Failed to parse query. > Схема "DEFAULT" не найдена > execute( conn, "drop table "+schemaName + "."+tableName+"'" ); > } > > I think this case should fail with error like "only cache created tables > can be removed with drop table. ", not with "scheme not found." > SQL-engine is supposed to accept and understand values it returns itself. > > > пт, 31 янв. 2020 г. в 11:29, Ivan Pavlukhin : > > > Vladimir, > > > > I will try to shed a light on this. > > 1. Statically configured tables in caches (QueryEntity) by default > > resides in a schema having the same name as a cache it belongs to > > ("default" is a cache and a schema name for a table Person in your > > example). > > 2. As you might know SQL literals are case-insensitive if they used > > without quotes. And Ignite SQL uses a quite naive approach for a > > case-insensitive comparison. It simply converts all case-insensitive > > names to upper case and compares after that. > > 3. And we observe consequences of such naive comparison. A schema name > > (equal to a cache name) is treated case-sensitive and saved as is > > ("default" in lower case). Query "SELECT ... FROM default.Person" > > passes schema name as case-insensitive. Ignite converts a schema from > > the query to upper case "DEFAULT" and searches for a schema with that > > name (using ordinary case-sensitive string comparison). But as there > > is only "default" in lower case it fails to find a schema. > > > > So, it is a bug. But for me personally it looks like the bug causes a > > not major usability problem. > > > > ср, 29 янв. 2020 г. в 12:27, Nikolay Izhikov : > > > > > > Vladimir. > > > > > > Please, provide a simple, self-contained reproducer to the issue you > > described. > > > > > > > 29 янв. 2020 г., в 11:16, Vladimir Steshin > > написал(а): > > > > > > > > Hi ppl. Wanted to ask is issue a bug. Minor propably. > > > > > > > > Recently noticed that one simple query returns a value which can't be > > found > > > > 'as is' in following query. I tried to find and drop all the tables I > > > > created with "create table": > > > > > > > > select schema_name, table_name, cache_name from sys.tables > > > > > > > > And there are tables which were not created with 'create table...'. For > > > > example, table 'default.Person' from the test/tutorial I was > > researching. > > > > Ok. I tried to delete them too. Now I know this is prohibited. But why > > I > > > > got error: scheme 'default' not found? I just received this schema name > > > > from previous query. > > > > > > > > To avoid this I had to capitalize schema name taking it into "": > > > > "default".Person. Then I got normal error like 'only cache created > > tables > > > > can be removed with drop table.'. > > > > > > > > One select returns value which can't be found in second select > > > > (delete/drop). Isn't it a bug from SQL's point of view? > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin
Re: Question: Table scheme 'default'
//Got a connectionConnection conn = ...; //execute() - is just a helper function. Creates prepared statement, pass params... //Get all the tables List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from SYS.TABLES"); for( List row : lst ){ String schemaName = (String)row.get(0); String tableName = (String)row.get(1); //Shows: "schema: default, table: PERSON" System.out.println("schema: " + schemName + ", table: " + tableName)); //Fails with with: java.sql.SQLException: Failed to parse query. Схема "DEFAULT" не найдена execute( conn, "drop table "+schemaName + "."+tableName+"'" ); } I think this case should fail with error like "only cache created tables can be removed with drop table. ", not with "scheme not found." SQL-engine is supposed to accept and understand values it returns itself. пт, 31 янв. 2020 г. в 11:29, Ivan Pavlukhin : > Vladimir, > > I will try to shed a light on this. > 1. Statically configured tables in caches (QueryEntity) by default > resides in a schema having the same name as a cache it belongs to > ("default" is a cache and a schema name for a table Person in your > example). > 2. As you might know SQL literals are case-insensitive if they used > without quotes. And Ignite SQL uses a quite naive approach for a > case-insensitive comparison. It simply converts all case-insensitive > names to upper case and compares after that. > 3. And we observe consequences of such naive comparison. A schema name > (equal to a cache name) is treated case-sensitive and saved as is > ("default" in lower case). Query "SELECT ... FROM default.Person" > passes schema name as case-insensitive. Ignite converts a schema from > the query to upper case "DEFAULT" and searches for a schema with that > name (using ordinary case-sensitive string comparison). But as there > is only "default" in lower case it fails to find a schema. > > So, it is a bug. But for me personally it looks like the bug causes a > not major usability problem. > > ср, 29 янв. 2020 г. в 12:27, Nikolay Izhikov : > > > > Vladimir. > > > > Please, provide a simple, self-contained reproducer to the issue you > described. > > > > > 29 янв. 2020 г., в 11:16, Vladimir Steshin > написал(а): > > > > > > Hi ppl. Wanted to ask is issue a bug. Minor propably. > > > > > > Recently noticed that one simple query returns a value which can't be > found > > > 'as is' in following query. I tried to find and drop all the tables I > > > created with "create table": > > > > > > select schema_name, table_name, cache_name from sys.tables > > > > > > And there are tables which were not created with 'create table...'. For > > > example, table 'default.Person' from the test/tutorial I was > researching. > > > Ok. I tried to delete them too. Now I know this is prohibited. But why > I > > > got error: scheme 'default' not found? I just received this schema name > > > from previous query. > > > > > > To avoid this I had to capitalize schema name taking it into "": > > > "default".Person. Then I got normal error like 'only cache created > tables > > > can be removed with drop table.'. > > > > > > One select returns value which can't be found in second select > > > (delete/drop). Isn't it a bug from SQL's point of view? > > > > > -- > Best regards, > Ivan Pavlukhin >
Re: Question: Table scheme 'default'
Vladimir, I will try to shed a light on this. 1. Statically configured tables in caches (QueryEntity) by default resides in a schema having the same name as a cache it belongs to ("default" is a cache and a schema name for a table Person in your example). 2. As you might know SQL literals are case-insensitive if they used without quotes. And Ignite SQL uses a quite naive approach for a case-insensitive comparison. It simply converts all case-insensitive names to upper case and compares after that. 3. And we observe consequences of such naive comparison. A schema name (equal to a cache name) is treated case-sensitive and saved as is ("default" in lower case). Query "SELECT ... FROM default.Person" passes schema name as case-insensitive. Ignite converts a schema from the query to upper case "DEFAULT" and searches for a schema with that name (using ordinary case-sensitive string comparison). But as there is only "default" in lower case it fails to find a schema. So, it is a bug. But for me personally it looks like the bug causes a not major usability problem. ср, 29 янв. 2020 г. в 12:27, Nikolay Izhikov : > > Vladimir. > > Please, provide a simple, self-contained reproducer to the issue you > described. > > > 29 янв. 2020 г., в 11:16, Vladimir Steshin написал(а): > > > > Hi ppl. Wanted to ask is issue a bug. Minor propably. > > > > Recently noticed that one simple query returns a value which can't be found > > 'as is' in following query. I tried to find and drop all the tables I > > created with "create table": > > > > select schema_name, table_name, cache_name from sys.tables > > > > And there are tables which were not created with 'create table...'. For > > example, table 'default.Person' from the test/tutorial I was researching. > > Ok. I tried to delete them too. Now I know this is prohibited. But why I > > got error: scheme 'default' not found? I just received this schema name > > from previous query. > > > > To avoid this I had to capitalize schema name taking it into "": > > "default".Person. Then I got normal error like 'only cache created tables > > can be removed with drop table.'. > > > > One select returns value which can't be found in second select > > (delete/drop). Isn't it a bug from SQL's point of view? > -- Best regards, Ivan Pavlukhin
Re: Question: Table scheme 'default'
Vladimir. Please, provide a simple, self-contained reproducer to the issue you described. > 29 янв. 2020 г., в 11:16, Vladimir Steshin написал(а): > > Hi ppl. Wanted to ask is issue a bug. Minor propably. > > Recently noticed that one simple query returns a value which can't be found > 'as is' in following query. I tried to find and drop all the tables I > created with "create table": > > select schema_name, table_name, cache_name from sys.tables > > And there are tables which were not created with 'create table...'. For > example, table 'default.Person' from the test/tutorial I was researching. > Ok. I tried to delete them too. Now I know this is prohibited. But why I > got error: scheme 'default' not found? I just received this schema name > from previous query. > > To avoid this I had to capitalize schema name taking it into "": > "default".Person. Then I got normal error like 'only cache created tables > can be removed with drop table.'. > > One select returns value which can't be found in second select > (delete/drop). Isn't it a bug from SQL's point of view?