Custom transformer for CacheJdbcPojoStore

[Alexey Kuznetsov-2]

Igniters!

We already have several cases when underlying database return something
that CacheJdbcPojoStore failed to transform to expected java types, for
example
we have two issues with Oracle Date and Timestamp.

All logic is encoded in  method:
"o.a.i.cache.store.jdbc.CacheAbstractJdbcStore.getColumnValue(ResultSet rs,
int colIdx, Class<?> type)".

This method contains some simple code that convert object received from
database to expected java class.

And we cannot handle vendor specific classes (for example
oracle.sql.TIMESTAMP) because ignite-core module cannot depends on vendor
JDBC drivers.

But user could write its own transformer and put it in class path and set
on CacheJdbcPojoStore configuration.

I'm thinking on introducing base class JdbcTypesTransformer with method
"Object transform(ResultSet rs, int colIdx, Class<?> type)" and move all
current logic there.

And it will be default transformer on JDBC POJO store.

And in case if one will face issue when default transformer failed to
transform value returned from database he will need to write a custom class
and put it into node classpath and set on JDBC POJO store configuration.

Any suggestions are welcome.

--
Alexey Kuznetsov

[dsetrakyan]

Inline…

On Thu, Jun 30, 2016 at 2:15 AM, Alexey Kuznetsov <[hidden email]>
wrote:

> Igniters!
>
> We already have several cases when underlying database return something
> that CacheJdbcPojoStore failed to transform to expected java types, for
> example
> we have two issues with Oracle Date and Timestamp.
>
> All logic is encoded in  method:
> "o.a.i.cache.store.jdbc.CacheAbstractJdbcStore.getColumnValue(ResultSet rs,
> int colIdx, Class<?> type)".
>
> This method contains some simple code that convert object received from
> database to expected java class.
>
> And we cannot handle vendor specific classes (for example
> oracle.sql.TIMESTAMP) because ignite-core module cannot depends on vendor
> JDBC drivers.
>

Hm… Why don’t you use reflection to handle such types? If the driver is
there, then load the class, otherwise don’t?


>
> But user could write its own transformer and put it in class path and set
> on CacheJdbcPojoStore configuration.
>
> I'm thinking on introducing base class JdbcTypesTransformer with method
> "Object transform(ResultSet rs, int colIdx, Class<?> type)" and move all
> current logic there.
>

Agree. How will the transformer be specified in configuration?

>
> And it will be default transformer on JDBC POJO store.
>
> And in case if one will face issue when default transformer failed to
> transform value returned from database he will need to write a custom class
> and put it into node classpath and set on JDBC POJO store configuration.
>
> Any suggestions are welcome.
>
> --
> Alexey Kuznetsov
>

[Alexey Kuznetsov-2]

Dmitry,

> Hm… Why don’t you use reflection to handle such types? If the driver is
> there, then load the class, otherwise don’t?
Yes, we could fix this issue with reflection. But I'm afraid that we will
end up with "dirty" code.
Also  with custom transformer user will be able to implement its own custom
logic. For example transform string "YES" to boolean true.

> Agree. How will the transformer be specified in configuration?
I'm planning to add getter and setter on CacheJdbcPojoStoreFactory. The
same way as for example: JdbcTypeHasher.


--
Alexey Kuznetsov

[dsetrakyan]

On Mon, Jul 4, 2016 at 3:49 AM, Alexey Kuznetsov <[hidden email]>
wrote:

> Dmitry,
>
> > Hm… Why don’t you use reflection to handle such types? If the driver is
> > there, then load the class, otherwise don’t?
> Yes, we could fix this issue with reflection. But I'm afraid that we will
> end up with "dirty" code.
> Also  with custom transformer user will be able to implement its own custom
> logic. For example transform string "YES" to boolean true.
>

The difference here is automatic vs. manual. I agree that we should have a
transformer, but we should still provide automatic mappings for some types
using reflection, as in most cases no additional logic will be required. No?


>
> > Agree. How will the transformer be specified in configuration?
> I'm planning to add getter and setter on CacheJdbcPojoStoreFactory. The
> same way as for example: JdbcTypeHasher.
>
>
> --
> Alexey Kuznetsov
>

[Alexey Kuznetsov-2]

I see your point now.

I think it is reasonable to have something that works out of the box even
if it will uses reflection.
And user could implement  custom logic if needed.
We will implement default transformer for all known cases.

On Tue, Jul 5, 2016 at 12:02 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Mon, Jul 4, 2016 at 3:49 AM, Alexey Kuznetsov <[hidden email]>
> wrote:
>
> > Dmitry,
> >
> > > Hm… Why don’t you use reflection to handle such types? If the driver is
> > > there, then load the class, otherwise don’t?
> > Yes, we could fix this issue with reflection. But I'm afraid that we will
> > end up with "dirty" code.
> > Also  with custom transformer user will be able to implement its own
> custom
> > logic. For example transform string "YES" to boolean true.
> >
>
> The difference here is automatic vs. manual. I agree that we should have a
> transformer, but we should still provide automatic mappings for some types
> using reflection, as in most cases no additional logic will be required.
> No?
>
>

--
Alexey Kuznetsov