Community mailing list archives
Re: Odoo on Crate Crazinessby
Sometimes I see these things and think, guess all the obvious issues are resolved then. Lets turn it up to 11.
No criticism btw, I have no idea what you are talking about to be honest.
On Mon, 1 Aug 2016 5:37 PM David Arnold <email@example.com> wrote:
Interesting article on randomized testing, also used at elasticsearch: http://blog.mikemccandless.com/2011/03/your-test-cases-should-sometimes-fail.htmlEl dom., 31 jul. 2016 a las 23:50, David Arnold (<firstname.lastname@example.org>) escribió:From crate docs: "If a query specification results in a
getoperation, changes are visible immediately. This is achieved by looking up the document in the translog first, which will always have the most recent version of the document. The common update and fetch use-case is therefore possible. If a client updates a row and that row is looked up by its primary key after that update the changes will always be visible, since the information will be retrieved directly from the translog. " sounds like good news, "client" presumably being the odoo codebase talking to the db backend. This would mean, even in a scaled out odoo application, if user sessions are sticky - a common pattern -, from the perspective of one single user, the DB appears to be always consistent. Am I right?
Questions:- atomicity only on the row level might probably not be enough.- No Transactions, what's optimistic concurrency control?Some related infos:Here is a list of be-tested soltions: https://github.com/aphyr/jepsenIt would be nice to get a clearer picture on pareto efficiency of such a solution, because one need to understand:Benefits can come at a cost, but those cost can only affect the beneficial part, so there should be an unbiased assessment as there can be a fair chance of being overall "better" (= pareto efficient).I think, if it's possible to eliminate concurrent writes out of the equation, the most business critical problem class disappears and writes architecture would be "quite" similar to the actual postgres setup, while batteries still included: speed of distributed reads, HA, replication, leadership election, split brain healing, etc.Do you know if one of the be-tested solutions https://github.com/aphyr/jepsen allows to specify a sinlge write point?Best