Re: Custom transformer for CacheJdbcPojoStore

2016-07-04 Thread Dmitriy Setrakyan
On Mon, Jul 4, 2016 at 3:49 AM, Alexey Kuznetsov 
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
>


Re: Custom transformer for CacheJdbcPojoStore

2016-07-04 Thread Alexey Kuznetsov
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


Re: Custom transformer for CacheJdbcPojoStore

2016-06-30 Thread Dmitriy Setrakyan
Inline…

On Thu, Jun 30, 2016 at 2:15 AM, Alexey Kuznetsov 
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
>