Hello! I think that key_type and value_type should be fully qualified:
key_type=some.package.WorkPlanKey,value_type=some.package.MWorkPlan If they don't match with type used with put(), you will not see the records in SELECT. Please also share the results of cache.size() after insert is done. Regards, -- Ilya Kasnacheev 2017-12-18 20:38 GMT+03:00 Matija Kejžar <matija.kej...@marand.si>: > Let’s say I create a table using Ignite DDL: > > > > *CREATE TABLE IF NOT EXISTS *M_WORK_PLAN ( > entity_id *VARCHAR*(36), > entity_version *INTEGER*, > owner_id *VARCHAR*(36), > materialisation_version *VARCHAR*(20), > ehr_id *VARCHAR*(36), > materialisation_time *TIMESTAMP*, > activation_time *TIMESTAMP*, > *PRIMARY KEY *(ehr_id, owner_id, entity_id) > ) *WITH *"template=partitioned,affinityKey=ehr_id,backups=1, > atomicity=transactional,cache_name=M_WORK_PLAN,key_type= > WorkPlanKey,value_type=MWorkPlan"; > > > > This creates a backing cache called M_WORK_PLAN. So far, so good. > > > > But if I then do a put into this cache through the Cache API (instead of > using an SQL insert) like this: > > > > ignite.cache(*“M_WORK_PLAN”*).put(*keyFromWP*(mWorkPlan), mWorkPlan); > > > > After which I then do an SQL query: > > > > select * from M_WORK_PLAN > > > > which returns an empty result set, 0 work plans. Now is this correct > behaviour? Should not the cache.put() statement effectively result in a new > entry in the M_WORK_PLAN table or am I misunderstanding what is going on > here? > > > > Furthermore, should not an SQL insert result in a cache.get() method on > the M_WORK_PLAN cache returning a matching entry from the table? > > > > Thanks, > > > > M. >
