You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metamodel.apache.org by Sagar Gandhi <ga...@live.com> on 2016/05/27 20:35:38 UTC
Discussion on METAMODEL-156 JdbcDataContext.getDefaultSchemaName
return SchemaName error
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
RE: Discussion on METAMODEL-156
JdbcDataContext.getDefaultSchemaName return SchemaName error
Posted by Sagar Gandhi <ga...@live.com>.
Hi Kasper,
It does make sense. We can use pattern matching for failsafe mechanism. First, We can check for the the URL format specified in document of known major databases and if that doesn't work , we can use pattern matching on same. Even if that does not work we can keep current mechanism as it as , as another failsafe mechanism.
> Date: Sun, 29 May 2016 21:48:24 -0700
> Subject: Re: Discussion on METAMODEL-156 JdbcDataContext.getDefaultSchemaName return SchemaName error
> From: i.am.kasper.sorensen@gmail.com
> To: dev@metamodel.apache.org
>
> 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 <ga...@live.com>:
> >
> >
> >
> >
> > 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: dev@metamodel.apache.org
> >
> >
> >
> >
> >
> > 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: gandhi.sagar@live.com
> >
> >> To: dev@metamodel.apache.org
> >
> >> 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
> >
> >
> >
> >
Re: Discussion on METAMODEL-156 JdbcDataContext.getDefaultSchemaName
return SchemaName error
Posted by Kasper Sørensen <i....@gmail.com>.
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 <ga...@live.com>:
>
>
>
>
> 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: dev@metamodel.apache.org
>
>
>
>
>
> 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: gandhi.sagar@live.com
>
>> To: dev@metamodel.apache.org
>
>> 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
>
>
>
>
RE: Discussion on METAMODEL-156
JdbcDataContext.getDefaultSchemaName return SchemaName error
Posted by ga...@live.com.
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: dev@metamodel.apache.org
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: gandhi.sagar@live.com
> To: dev@metamodel.apache.org
> 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
RE: Discussion on METAMODEL-156
JdbcDataContext.getDefaultSchemaName return SchemaName error
Posted by Sagar Gandhi <ga...@live.com>.
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: gandhi.sagar@live.com
> To: dev@metamodel.apache.org
> 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