Unable to use SUBSTR inside TO_DATE in Derby Embedded Database - derby

Question

I am using derby embedded database for my Maven test cases. And I am not able to use SUBSTR inside TO_DATE, its giving error.
Actually it was used for original application which is connected to oracle db. Now I am writing Maven test cases, with derby embedded db and unable to execute this one. The thing is I should not modify the original query and I need some workaround to rectify this issue.
My query will be like this.
SELECT TO_DATE (SUBSTR (testdate, 1, 9), 'DD-MM-RR') FROM testtable
Please help me on this issue. Thanks.

Answer 1

Substr cannot be used with DATE. You cannot not override it. SQL is not easily re-used between database. The easiest part is to change the sql.
The harder part is to step deep into derby:
If you want to make this work without changing the query, you could wrap the connection or the DataSource and change the sql on a lower Level.
For this to work you need access to the Connection Object in your test:
Connection wrapped = new WrappedConnection(originalConnection);
This is a short example of a wrapped Connection, with a migrate function (this is basically the Adapter Pattern:
public class WrappedConnection implements Connection
{
private final Connection origConnection;
public WrappedConnection(Connection rv)
{
origConnection = rv;
}
//I left out other methods, that you have to implement accordingly
public PreparedStatement prepareStatement(String pSql) throws SQLException
{
//this you have to implement yourself
//this will serve as a bridge between oracle and derby
String sql = migrate(sql);
return sql;
}
}
The migrate function could to something like this:
public String migrate(String sql)
{
return sql.replace("SUBSTR", "SUBSTR_DATE");
}
But you would have to create your own Derby Function SUBSTR_DATE.

Answer 2

I can think of 2 options... I don't know how much sense either makes but...
Create a sub class of the original, and (assuming that the line is only used in one method of that class) simply override that single method. and leave the rest of the code the same.
If the class that calls this SQL send the message to a customised 'sendSQLStatement(String sql) tpe method, this would handle all the creation of the statement object, surround with try / catch error handling etc, and return the result set, you could set an overide in the method to check for the DB engine being used.
This info is obtainable from the databaseMetaData.getDatabaseProductName(), or alternatively from the get .getDriverName() method. you then test this string to see if it contains the word 'derby' and if yes send a different type of SQL.
Of course later on down the road you will need to perform a final test to ensure that the original Oracle code still works.
You may even take the opportunity to modify the whole code snippet to make it more DB agnostic (ie cast the value to a string type (or a date from a long) and then do the substring function.