Ilya, This won't help, since the problem here is that CQ doesn't return all needed keys.
Evgenii вт, 15 сент. 2020 г. в 02:28, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: > Hello! > > Maybe keys may be queued from the CQ to be revisited later with > transaction per key approach. > > Regards, > -- > Ilya Kasnacheev > > > пн, 14 сент. 2020 г. в 21:15, Evgenii Zhuravlev <e.zhuravlev...@gmail.com > >: > >> No, I don't see other ways to do this transactionally, as CQ itself is >> not transactional. >> >> Evgenii >> >> чт, 10 сент. 2020 г. в 00:52, ssansoy <s.san...@cmcmarkets.com>: >> >>> unfortunately the 's' on B here can't be derived from a number 0..n - >>> e.g. it >>> isn't a numeric id. >>> >>> E.g. in practice lets say: >>> >>> A is a "Location" >>> it has properties: "city", "street" etc >>> >>> B is a "Person" with key: >>> p = city >>> q = street >>> r = social security number >>> >>> E.g. an A and associated B's are updated in a transaction, we want our >>> client app to see the updated A and B's where the Person lives at that >>> that >>> Location. >>> >>> E.g. A is updated and our continuous query on A picks up: >>> city = London >>> street = Downing Street >>> >>> We would like to say: >>> Select * from B where city="London" and street="Downing Street" >>> >>> Is there any way at all in Ignite to do this transactionally, so if an A >>> and >>> associated B's are updated in one transaction (e.g. a street is renamed >>> from >>> "Downing Street" to "Regent Street"), then our client app can see them >>> consistently? >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >>> >>
