Hi Sagar, Sorry for the late reply, but I didn't have time before now. I think it makes sense to do what you're talking about - to do more specific pattern matching on the URL. It seems to me though that many drivers have a lot of different supported styles of connection strings. So the way of coding this should be pretty defensive: Assume that it's not going to work, because the connection string is (almost) arbitrary so it can be anything. We should thus be fairly specific regarding the patterns that we try to match with. For example I think it would make sense to match with database-specific patterns such as "jdbc:mysql://.+/(.+)\??.*" but I wouldn't want to get rid of the "mysql" in that pattern because I have no way of anticipating if database vendor XYZ has a similar url pattern with completely different semantics though. Makes sense?
Kasper 2016-05-28 10:24 GMT-07:00 <[email protected]>: > > > > > Any thoughts or updates on this ？ > > > > From: Sagar Gandhi > > Sent: Saturday 28 May 3:03 am > > Subject: RE: Discussion on METAMODEL-156 JdbcDataContext.getDefaultSchemaName > return SchemaName error > > To: [email protected] > > > > > > Brief example : > > MySQL URL format is > jdbc:mysql://[host1][:port1][,[host2][:port2]]...[/[database]] > [?propertyName1=propertyValue1[&propertyName2=propertyValue2]...] > > > example 1 :jdbc:mysql://DBNAME_test:3306/DBNAME?user=DBNAME_test > > example 2 : jdbc:mysql://DBNAME:3306/DBNAME_test?user=DBNAME > > In first case , we expect the default database name as DBNAME but in second > case we expect as DBNAME_test. Now coming to metamodel , If we check contains > then default db name really depends on index of schemaNames array. If we > check largest db name , as suggested in comment section of bug then also it > will create a problem (first case). > > So If we can handle the such known cases for major databases then it will be > far more helpful.For rest of the databases and custom drivers , our current > behaviour will remain as it is with bug fix as fail-safe mechanism. > > @KasperThis might need refactoring the method as you mentioned in comment. > > > > >> From: [email protected] > >> To: [email protected] > >> Subject: Discussion on METAMODEL-156 JdbcDataContext.getDefaultSchemaName >> return SchemaName error > >> Date: Sat, 28 May 2016 02:05:38 +0530 > >> > >> Hi all, > >> I started working on starter Bug Metamodel 156 titled >> "JdbcDataContext.getDefaultSchemaName return SchemaName error". > >> Currently it finds database from URL using contains method, but if host name >> or directory (in case of HSQLDB) or any custom driver specific property name >> and schema name (non-default) are same then we can get wrong result. So I >> think we need to handle database specific URLs as much as possible and keep >> current behaviour as fail-safe mechanism. > >> Example : for MySQL , database URL format is >> jdbc:mysql://[host1][:port1][,[host2][:port2]]...[/[database]] >> [?propertyName1=propertyValue1[&propertyName2=propertyValue2]...](Referred >> from >> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html) > >> So we can do following steps1. find last index of /2. find first index of >> ?3. If ? index is -1 then substring (last index of /) + 1 to end of url4. If >> ? index is not -1 then substring (last index of /)+1 to (first index of ?)5. >> If substring length is greater than 0 after trim then its databasename. > >> > >> Above is just pseducode , we can come with better strategy. Same way we can >> do it for MSSQL, DB2, Hive, HSQLDB. For Microsoft SQL Server , we can handle >> both JTDS and Microsoft Driver URL formats. If our new strategy fails to >> get database name due to different driver issues then current behaviour with >> bug fix can remain as fail-safe mechanism. > >> > >> Please do share your thoughts on this. > >> > >> Thanks ,Mr.Sagar Gandhi,Senior Software Engineer,eQ Technologic Inc.Pune- >> India(+91)9028440503 > > > >
