Github user kaspersorensen commented on the pull request:
https://github.com/apache/metamodel/pull/58#issuecomment-148908260
The build is failing so I doubt this is a good approach, but I'd like to
give some input and thoughts... I was trying to read up on JDBC spec to
understand what can be done here.
In section 13.4.2 of the JDBC 4.1 spec [1] it shows that proper SQL
statement escape would be
date: ```{d 'yyyy-mm-dd'```
time: ```{t 'hh:mm:ss'}```
timestamp: ```{ts 'yyyy-mm-dd hh:mm:ss.f . . .'}```
I'm always quite skeptical to see if the JDBC drivers out there _actually_
implement such details of the JDBC spec. Often I have found that
implementations are not spot on in that regard. But I think the above could
form the basis of a good default. We could override the default in case of
deviating JDBC drivers.
Our normal way of handling such deviations is to not rely on the
FormatHelper (because it is generic and context-free) but rather rely on the
```IQueryRewriter``` interface, which actually has the method
```rewriteFilterItem(...)``` method. There's a hierarchy of classes that
implement the interface and the default implementation (which most deviating
implementations extend from) does delegate eventually to FormatHelper. But
that's what we should change IMO. So instead of changing FormatHelper I would
change ```DefaultQueryRewriter```.
I would also want to cover this in all of our JDBC integration tests. Those
aren't part of the Travis build but once we have a good implementation going
then I am happy to test at least on the usual suspect databases such as
PostgreSQL, MySQL, MS SQL Server, DB2 and Oracle.
[1]
http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
