IRC logs of #tryton for Monday, 2011-06-13

chat.freenode.net #tryton log beginning Mon Jun 13 00:00:04 CEST 2011
-!- ikks(~ikks@186.83.199.77) has joined #tryton00:41
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton01:05
-!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton01:23
-!- alimon(~alimon@187.156.103.195) has joined #tryton01:57
-!- gremly(~gremly@200.106.202.91) has joined #tryton02:29
-!- yangoon(~mathiasb@p549F3CE2.dip.t-dialin.net) has joined #tryton05:18
-!- nicoe(~nicoe@100.169-66-87.adsl-dyn.isp.belgacom.be) has joined #tryton06:09
-!- nicoe_(~nicoe@100.169-66-87.adsl-dyn.isp.belgacom.be) has joined #tryton09:01
-!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton09:04
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton09:13
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:59
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has joined #tryton10:15
-!- meanmicio(bec3320f@gateway/web/freenode/ip.190.195.50.15) has joined #tryton10:59
meanmicioHello all. Do we have a context variable for the current user id ?11:06
cedkmeanmicio: Transaction().user11:08
meanmiciocedk : thanks. Could not find uid ;-)11:09
cedkmeanmicio: but be careful that we have some kind of sudo11:11
cedkmeanmicio: and then the user is stored in the context11:11
meanmiciocedk . ok. I look into it now in the documentation11:13
cedkwe should perhaps add a get_user on Transaction11:16
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton11:58
-!- cheche(cheche@46.25.80.67) has joined #tryton12:53
-!- bechamel(~user@host-85-201-144-79.brutele.be) has joined #tryton13:31
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton14:11
-!- woakas(~woakas@200.106.202.91) has joined #tryton14:17
-!- yangoon(~mathiasb@p549F2ACF.dip.t-dialin.net) has joined #tryton14:31
-!- yangoon(~mathiasb@p54B4E5F1.dip.t-dialin.net) has joined #tryton15:39
-!- nicoe(~nicoe@100.169-66-87.adsl-dyn.isp.belgacom.be) has joined #tryton16:37
-!- alimon(~alimon@187.156.103.195) has joined #tryton16:45
-!- cheche(cheche@46.25.80.67) has joined #tryton17:04
-!- gremly(~gremly@200.106.202.91) has joined #tryton17:55
-!- elbenfreund(~elbenfreu@p54B93B84.dip.t-dialin.net) has joined #tryton18:22
-!- alimon(~alimon@187.156.103.195) has joined #tryton18:22
-!- gremly(~gremly@200.106.202.91) has joined #tryton19:10
-!- sharoon(~sharoon@173-9-190-185-miami.txt.hfc.comcastbusiness.net) has joined #tryton20:09
sharooncedk: ping20:11
cedksharoon: pong20:12
sharooncedk: do you have amin to discuss about sequences20:13
sharooncedk: the timestamp based sequences are anyway not continuous, can we not take them outside the transaction to make them faster and remove the most common reason for serialisation errors ?20:14
cedksharoon: I must be in the transaction to ensure to not have duplicates20:15
sharooncedk: is there no way to avoid duplicates ?20:17
cedksharoon: what is the problem?20:17
sharooncedk: for heavy volume systems the most common reason for transaction errors is the sequence20:18
sharooncedk: just trying to find a way outside it20:18
cedksharoon: what do you call heavy volume?20:19
-!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton20:19
sharooncedk: many simultaneous transactions20:19
sharooncedk: (not read) but write transactions20:19
cedksharoon: which transaction from where?20:19
sharooncedk: both direct python and also over the client (through dispatcher)20:20
cedksharoon: but what is required sequences?20:22
sharooncedk: there is no constraint on gap20:27
sharooncedk: we dont have problem with gaps (infact its desired020:28
cedksharoon: ok but which Models are created on heavy load and require sequence?20:28
sharooncedk: sale.sale, account.invoice, stock.invoice.out20:29
sharoon*stock.shipment.out20:29
cedksharoon: I try to understand, how many sale do you have?20:30
sharooncedk: on private chat20:31
cedksharoon: ok it comes from website20:32
cedksharoon: you should not run the workflow on the fly for website orders20:33
sharooncedk: ok20:35
sharooncedk: At the moment i have a workaround which is using rabbit mq and celery which reattempts the workflow change. on transaction rserialisation error, it reattempts20:36
cedksharoon: I think a webshop should not create sale order but directly shipment and invoice20:38
cedksharoon: and indeed not directly those records but should post to a order queue and let the system process them when it  has time20:39
cedkit is the only good way to get good perf20:39
sharooncedk: thats how it is done, but that works like a bottleneck because it truly does it one after the other20:39
cedkwhich is almost what you did with the mq20:39
cedksharoon: a bottleneck for what?20:40
sharooncedk: bottleneck for processing during high transaction times of course20:41
cedksharoon: don't understand20:41
cedksharoon: if there is a queue there is no bottleneck20:41
bechamelmaybe the queue gets bigger and bigger20:42
-!- meanmicio(bec3320f@gateway/web/freenode/ip.190.195.50.15) has joined #tryton20:42
meanmiciohappy to announce that the medical kernel data model port is done.20:43
cedkmeanmicio: great20:43
meanmicioin the main module only. Now is time to start with the reports20:43
meanmiciocedk : I have to polish some stuff still, like the on_change_with... I want it to evaluate also with the same field, so it always computes the right formula20:45
meanmiciocedk : but are minor issues, something that can be done. Hope to have the rest of modules by the end of this week. They should not be that hard to port.20:47
cedkmeanmicio: ok I will try to find time to test/review it20:47
sharooncedk: bechamel: will let you know after the test20:48
cedksharoon, bechamel: there is also the possiblilty to make sharding with sequences20:48
meanmiciobrb20:49
bechamelsharding is webscale ! :D20:49
sharoonbechamel: cedk: so are we webscale ;) ?20:49
bechamelcedk: but I don't see what you mean by sharding in this context20:50
cedkby sharding on sequence, I mean define a business logic per example on sale (shop, warehouse, etc.) and define different sequence on those records20:50
cedkuse those sequences instead of the default one20:51
cedkand you can add a prefix/suffix on each sequences to make the differences20:51
sharooncedk: sorry, it went above my head20:53
bechamelcedk: good idea20:53
bechamelcedk: and there is no way to have a better time resolution ? (I mean milli- or micro- seconds)20:53
cedkbechamel: it is not the problem20:54
cedkbechamel: the issue is that we are in serialized transaction20:54
sharoonbechamel: there is patch which improves resoltion (which is not the highest ~= the system clock)20:54
sharoons/not/now20:54
-!- ciupicri(~ciupicri@81.180.234.249) has joined #tryton20:56
sharooncedk: does this solve the problem of transaction serialisation ?20:57
cedksharoon: sharding?20:58
sharooncedk: yes20:58
cedksharoon: partially, it depends on how much you will shard20:58
-!- FWiesing(~franz@mail.tryton.at) has joined #tryton20:58
sharooncedk: also on a separate note, it is impossible to catch Transaction Serialisation errors generically for all databases (though we have an abstraction of cursor)20:59
sharooncedk: one way to do it to catch OpenrationError, but isnt it too general ?21:00
cedksharoon: don't know21:00
sharooncedk: do you think we can implement a custom exception on the cursor level which is raised instead of the db adaptor specific one ?21:01
cedksharoon: don't understand21:01
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton21:02
sharooncedk: for example the serialisation error raised is TransactionRollbackError (http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.TransactionRollbackError) when psycopg2 is used as api and postgres is backend21:03
sharooncedk: if we handle this error anywhere in module code, then we have to import from psycopg2 and then code becomes dependent on a single backend21:03
cedksharoon: it is not standard to DB API 2.021:05
sharooncedk: from DB API 2.0 i think OperationalError is a better error to handle ?21:07
sharooncedk: and TransactionRollbackError is a subclass of OperationalError21:07
cedksharoon: you will catch too much errors21:07
sharooncedk: exactly what i thought too21:10
sharooncedk: if the cursor api of tryton which anyway is an abstraction) implements some level of abstraction on transaction rollbacks it would have been better21:11
sharooncedk: especially from something like a dispatcher catching operationalerror is too much defensive21:12
sharoonACTION chacking what django does21:12
sharooncedk: https://code.djangoproject.com/browser/django/trunk/django/db/transaction.py#L2321:13
cedksharoon: I don'T understand21:14
sharooncedk: the transaction error is an abstration over all database transaction errors across all backends (postgres, mysql etc)21:15
sharooncedk: so in a mdoule code all that needs to be handled is this error, and programmer need not write explicit code to handle transaciton error of postgres, mysql and sqlite21:15
cedksharoon: I don't see that in the link you give and I don't understand what is "transaciton error"21:16
sharooncedk: the doc is here21:16
sharoonhttps://docs.djangoproject.com/en/dev/topics/db/transactions/21:16
cedksharoon: I doesn't explain what is a "transaction error"21:17
sharooncedk: it is a very wide abstration - it encapsulates all errors that occur in transaction21:19
cedksharoon: like the OperationalError21:19
sharooncedk: yes - if openrationerror is only used by the DB API21:20
cedksharoon: shoudl check of sqlite and mysql lib has the TransactionRollbackError exception21:27
sharooncedk: ok21:27
-!- vladimirek(~vladimire@bband-dyn79.178-41-183.t-com.sk) has joined #tryton21:31
-!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton21:43
-!- alimon(~alimon@201.158.247.118) has joined #tryton21:55
-!- saxa(~sasa@189.26.255.43) has joined #tryton22:02
ciupicrisharkcz, sorry for the bad English in the last comments on the tryton accounting package reviews. It was morning after a pretty long night.22:21
-!- cheche(cheche@46.25.80.67) has joined #tryton23:03

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!