I am making a fair amount of assumptions: 1. aff_b means that table c has an affinity key that includes table b's id plus table c's id. Is that true? 2. I get that table c has a foreign key to table b. 3. You are doing puts to your caches, then use the sql query engine with distjoins=false hoping to join the 3 tables. Is that all correct?
We are doing this very thing. We need to differentiate the fk in your rdbms and your affinity key in ignite. In ignite, table/cache c will have: 1. An object attribute and column of bid (b.id or b_id if that makes more sense). 2. An affinity key of aid + cid (table a's pk/id plus table c's pk/id). The question becomes, on a put to table/cache c, how do we get a.id since it is not in table c's columns/objectGetters? Answer: We created a facade of the ignite thick client and we do puts via our facade. Our facade then runs a query like "select aid from b where b.id = ?" and we pass in the value of c.getbid() for ?. We use the return value from that query to generate the affinity key. It does say that you need to populate or do puts to table/cache b before c (unless you have another way to get the value a.id when putting object c). Hopefully this helps but might possibly cause more questions. Cheers, Craig ________________________________ From: manueltg89 <manuel.trinidad.gar...@hotmail.com> Sent: Thursday, June 11, 2020 1:05 PM To: user@ignite.apache.org <user@ignite.apache.org> Subject: Re: Non Distributed Join between tables CAUTION: This email originated outside 24 Hour Fitness. Do not click links or open attachments unless you recognize the sender and know the content is safe. Yes, table c is child of table b. But, It is redundant in my RDBMS, Would have other solution whitout changing my schema? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
