<div dir="ltr">Regardless the underlying mechanisms, there's still a logical distinction between updates and inserts, and here the proposed algorithms seem relevant, if I understand, only for inserted rows: step 4 of reading says "<span style="background-color:rgb(245,245,245);color:inherit;font-family:hack;font-size:13px;white-space:pre-line">The client code culls rows where the transactionUUID existed in the IncompleteTransactions table.</span>" which means, applied to the Inventory case, that it will not return any Entity that is currently modified in an ongoing transaction. Which would not be the desired behaviour for us, we'd like to have the pre-transaction state.<br><div><br></div><div>It's explicitly written in the post, quoting:</div><div>"<span style="background-color:rgb(245,245,245);color:inherit;font-family:hack;font-size:13px;white-space:pre-line">This is just an example, one that is reasonably performant for ledger-style <b>non-updated inserts</b>. For <b>transactions involving updates</b> to possibly existing data, more effort is required, generally the client needs to be smart enough to merge updates based on a timestamp, with a periodic batch job that cleans out obsolete inserts.</span>"</div><div><br></div><div>Or is there something I haven't understood here?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 3:24 PM, John Sanda <span dir="ltr"><<a href="mailto:jsanda@redhat.com" target="_blank">jsanda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span class=""><div>On Dec 19, 2016, at 3:09 AM, Joel Takvorian <<a href="mailto:jtakvori@redhat.com" target="_blank">jtakvori@redhat.com</a>> wrote:</div><br class="m_2947496518773346222Apple-interchange-newline"></span><div><div dir="ltr"><span class="">Thanks John, very interesting reading.<div><br></div></span><div>No luck for us in inventory, as there's essentially updates rather than inserts, which is a bit more complicated than the solution described: "<span style="background-color:rgb(245,245,245);color:inherit;font-family:hack;font-size:13px;white-space:pre-line">generally the client needs to be smart enough to merge updates based on a timestamp, with a periodic batch job that cleans out obsolete inserts”</span></div></div></div></blockquote><div><br></div><div>Can you explain more what you mean about there being updates rather than inserts? Inserts and updates are the same in Cassandra. Think of a put operation on a map.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><span style="background-color:rgb(245,245,245);color:inherit;font-size:13px;white-space:pre-line"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="background-color:rgb(245,245,245);color:inherit;font-size:13px;white-space:pre-line"><font face="arial, helvetica, sans-serif">But now we're considering the alternative of reading/writing the whole graph at once and process queries in memory. If "the whole graph" is too big to fit in memory without problems, then we should find a way to partition it.</font></span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 17, 2016 at 2:54 AM, John Sanda <span dir="ltr"><<a href="mailto:jsanda@redhat.com" target="_blank">jsanda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This thread post <a href="https://goo.gl/8cpSwM" target="_blank">https://goo.gl/8cpSwM</a> fro<wbr>m cassandra-users list has a good write up on an approach for implementing transactions across multiple tables in order to provide stronger consistency. I found it particularly interesting in light of the discussions of inventory and consistency.<span class="m_2947496518773346222HOEnZb"><font color="#888888"><div><br></div><div>- John</div></font></span></div><br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<br>hawkular-dev mailing list<br><a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br></div></blockquote></span></div><br></div><br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br></blockquote></div><br></div>