Re: JDBC store Date deserialization problem

Thanks Vasiliy, the transformer indeed still works fine. I wasn't properly installed in the 2.2.0 test I used, my mistake. Franck -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC store Date deserialization problem

My bad, the issue is not resolved but my transformer workaround was not properly installed. Franck -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC store Date deserialization problem

Hi Val, Was this fixed in 2.2.0? It looks like my workaround doesn't work anymore with that version... SQL_TYPES now includes java.util.Date, however the type of my binary field is ignored when serializing by the (very strange...) implementation of

Re: Security question

Thanks Dmitry, that makes sense, we will make sure that client-side code is trusted. Franck -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Security question

Wow. That means any client who can get past node authentication on join can do anything they like on all caches, including all admin commands. The node validation logic won't help at all - the join request may claim that a given security processor is used, but subsequent requests can perfectly be

Security question

Hi all, Stepping through the code during a cache.get() request from a client node to a server node, I don't see that GridSecurityProcessor.authorize will ever be called on the server node? Authorize is called on the client node, but on the server node the code goes straight to

Re: Cache pre-loading question

IgniteCache has a loadCache method and that is what I am using currently, but I have seen many recommendations here and in the docs to a streamer rather than loadCache (because loadCache is not transactional, can lead to out-of-sync data if the topology changes...), e.g.:

Re: Cache pre-loading question

Hi Alex, what do you mean by custom? I am indeed using a CacheJdbcPojoStore, it has the method I need (loadCache(final IgniteBiInClosure clo, @Nullable Object... args)) however I can't obtain a reference to the store from my ignite instance. I can try to build an instance of the store

Re: Cache pre-loading question

Hi Alex, what do you mean by custom? I am indeed using a CacheJdbcPojoStore, it has the method I need (loadCache(final IgniteBiInClosure clo, @Nullable Object... args)) however I can't obtain a reference to the store from my ignite instance. I can try to build an instance of the store

Cache pre-loading question

Hi all, I am trying to figure out the best approach for pre-loading cache entries from a SQL DB on startup. I have read the recommendations to use a client node and a data streamer to pre-load cache data on startup. One issue I see with the approach however, compared with cache.loadCache(), is

Re: Authentication

Hi all, I am reviving this thread because as far as I can tell the initial question was not answered, and I am hitting the same problem: "* when a node starts up it needs to fetch the local password and store it in it's own configuration " ... and I can't figure out how to do that?? The only

Re: Custom SecurityCredentialsProvider and SecurityCredentials

What is even more confusing is that SecurityCredentialsProvider is in fact only used in GridClient and GridTcpRouter configurations. If I understans correctly GridClient is in turn only used by the cmd line client, and by the deprecated legacy jdbc connection. So, what is the proper strategy for

Re: Confused about QueryEntity configuration

Hi Val, I am able to use _key sucessfully, that is acceptable. I tried defining an alias, using all combinations of _key/DB name and all orders, and I couldn't get that to work. Looking through the code it seems to me that aliases are only used to map result column names to binary object field

Re: Custom SecurityCredentialsProvider and SecurityCredentials

I can implement my own flavor of SecurityCredentialsProvider yes. But the Ignite code will not use it no matter what I do - unless I missed something. Franck -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Confused about QueryEntity configuration

Thanks Val, I meant #1 indeed. Using _key works. What I'd like to achieve is for users to be able to use javaNames in their queries, rather than "_key" or databaseFieldName: I consider the javaName as a public API, whereas "_key" or the database field name are implementation details that are

Custom SecurityCredentialsProvider and SecurityCredentials

Hi all, I can't figure out how to install a custom security credentials provider? The javadoc says ... however GridClientConfiguration hardcodes an instance of SecurityCredentialsBasicProvider, and ServerImpl directly gets credentials from

Re: Confused about QueryEntity configuration

Thanks Vasiliy! #1 works fine, I can go with that I can't get #2 to work, with this configuration: I get the exception below: -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Confused-about-QueryEntity-configuration-tp16281p16359.html Sent from the Apache

Re: JDBC store Date deserialization problem

Thanks Val! -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-tp16276p16355.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failure to deserialize simple model object

Awesome, thanks! Franck -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p16333.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: JDBC store Date deserialization problem

BTW, if I remember correctly the server write -2 as a type ID because java.util.Date is not in this array: org.apache.ignite.internal.processors.query.QueryUtils#SQL_TYPES If I use java.sql.Date in the Ignite configuration I get a different exception (Wrong value has been set). Franck --

Re: JDBC store Date deserialization problem

I understand for the store implementation, thanks. I have attached a sample project, simply run this test (Ignite and DB are embedded): ignite-binary-sample.zip

Re: Confused about QueryEntity configuration

empNo is in fact the key. I have attached a small sample project that demonstrates the problem; I can in fact make the query work normally if I add keyFieldName=empNo to the queryEntity configuration. I don't see why this is required, for example with another cache that uses a composite key:

Re: Confused about QueryEntity configuration

After some experimentation I have one answer, and more questions :) I guess QueryEntity.keyType is only used to identify which objects will be considered in the queries - I had forgotten that a cache can contain objects of multiple types. I am still struggling to configure queries for a JDBC

Confused about QueryEntity configuration

Hi all, Despite reading the doc many times I can't quite figure out how SQL queries should be configured. In particular what is query.keyType used for in that context? The key type doesn't seem to have any impact on what SQL queries I can execute on the cache? Does it simply have to match the

Re: JDBC store Date deserialization problem

Here is a related issue: if I install a custom JdbcTypesTransformer on my JDBC store, I have to make that transformer class available on client nodes - else discovery fails with the exception below. It would be nice if client nodes didn't have to have dependencies on cache store implementations,

JDBC store Date deserialization problem

Hi all, I am using a JDBC store with storeKeepBinary enabled, and getting a single value that has a SQL date column. The JdbcTypeField for that column has javaFieldType == java.util.Date. The JdbcTypesDefaultTransformer however return java.sql.Date as a value for the field: As a result the

Re: Centralized configuration management

Thanks Alex! -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159p16168.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Client requires DataSource bean configuration copy

In case someone else hits this, the issue is easily resolved by embedding cachestore and datasource facotyr beans in the cache bean, instead of using spring references: Franck -- View this message in context:

Re: Centralized configuration management

Hi Alex, Regarding this statement: "When you destroy or create a cache from a client node, there generally no need to have/propagate the configuration manually to remote nodes. *On join/restart*, a node will find out the caches configured in the cluster and all the required routines will take

Re: Centralized configuration management

I need to be a bit more specific I guess. I need the ability to create new caches, or to update the configuration of existing caches. When updating the configuration of a cache other caches should not be affected - so a node restart is not a great option. Would this plan work: - The controller

Centralized configuration management

Hi all, I am trying to design a controller that will be responsible for managing the cache configuration of all nodes in a cluster. Having read this in the docs: "All caches defined in Ignite Spring XML configuration on any cluster member will also be automatically created and deployed on all

Re: Failure to deserialize simple model object

My bad, here is the whole project. Franck ignite-binary-sample.zip -- View this message in context:

Re: Failure to deserialize simple model object

BTW if you experiment around you will want to clean up the work/marshallers directories on server & client between tests; once the typeId is saved there the problem goes away obviously... Franck -- View this message in context:

Re: Failure to deserialize simple model object

Hi Mikhail, I have extracted the simplest possible configuration, I have attached a self-contained project that uses an in memory H2 database and reproduces the problem, here are the steps: 1. mvn install in the root 2. run the junit test org.apache.ignite.sample.test.ServerTests#runIgnite (this

GridGain vs. ignite maven artifacts

Hi all, the online Web console mentioned in the Ignite docs generates code that points to 2.1.2 ignite artifacts in this repository: On maven central the latest release I can find is 2.0.0... so what do you recommend I should use? Are the GridGain artifacts a fork of the Ignite code

Re: Client requires DataSource bean configuration copy

Thanks Val, that makes sense. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Client-requires-DataSource-bean-configuration-copy-tp15491p15576.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Client requires DataSource bean configuration copy

I have a single server defining a cachestore on top of a JDBC data source using the attached spring configuration. I connect a single client, and I don't need to replicate the cache configuration in the client: the client downloads it from the server on startup. However I still need to declare the

Re: Failure to deserialize simple model object

Hi Mikhail, I have subscribed to the mailing list - just didn't long enough before posting :( I have attached the POM. Since my post I tried a couple more things: - I removed the CacheConfiguration elements from the client; I can still find the server's partitioned caches in