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

chat.freenode.net #tryton log beginning Mon Jun 13 00:00:04 CEST 2011
2011-06-13 00:41 -!- ikks(~ikks@186.83.199.77) has joined #tryton
2011-06-13 01:05 -!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton
2011-06-13 01:23 -!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton
2011-06-13 01:57 -!- alimon(~alimon@187.156.103.195) has joined #tryton
2011-06-13 02:29 -!- gremly(~gremly@200.106.202.91) has joined #tryton
2011-06-13 05:18 -!- yangoon(~mathiasb@p549F3CE2.dip.t-dialin.net) has joined #tryton
2011-06-13 06:09 -!- nicoe(~nicoe@100.169-66-87.adsl-dyn.isp.belgacom.be) has joined #tryton
2011-06-13 09:01 -!- nicoe_(~nicoe@100.169-66-87.adsl-dyn.isp.belgacom.be) has joined #tryton
2011-06-13 09:04 -!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton
2011-06-13 09:13 -!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton
2011-06-13 09:59 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2011-06-13 10:15 -!- pjstevns(~pjstevns@helpoort.xs4all.nl) has joined #tryton
2011-06-13 10:59 -!- meanmicio(bec3320f@gateway/web/freenode/ip.190.195.50.15) has joined #tryton
2011-06-13 11:06 <meanmicio> Hello all. Do we have a context variable for the current user id ?
2011-06-13 11:08 <cedk> meanmicio: Transaction().user
2011-06-13 11:09 <meanmicio> cedk : thanks. Could not find uid ;-)
2011-06-13 11:11 <cedk> meanmicio: but be careful that we have some kind of sudo
2011-06-13 11:11 <cedk> meanmicio: and then the user is stored in the context
2011-06-13 11:13 <meanmicio> cedk . ok. I look into it now in the documentation
2011-06-13 11:16 <cedk> we should perhaps add a get_user on Transaction
2011-06-13 11:58 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2011-06-13 12:53 -!- cheche(cheche@46.25.80.67) has joined #tryton
2011-06-13 13:31 -!- bechamel(~user@host-85-201-144-79.brutele.be) has joined #tryton
2011-06-13 14:11 -!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton
2011-06-13 14:17 -!- woakas(~woakas@200.106.202.91) has joined #tryton
2011-06-13 14:31 -!- yangoon(~mathiasb@p549F2ACF.dip.t-dialin.net) has joined #tryton
2011-06-13 15:39 -!- yangoon(~mathiasb@p54B4E5F1.dip.t-dialin.net) has joined #tryton
2011-06-13 16:37 -!- nicoe(~nicoe@100.169-66-87.adsl-dyn.isp.belgacom.be) has joined #tryton
2011-06-13 16:45 -!- alimon(~alimon@187.156.103.195) has joined #tryton
2011-06-13 17:04 -!- cheche(cheche@46.25.80.67) has joined #tryton
2011-06-13 17:55 -!- gremly(~gremly@200.106.202.91) has joined #tryton
2011-06-13 18:22 -!- elbenfreund(~elbenfreu@p54B93B84.dip.t-dialin.net) has joined #tryton
2011-06-13 18:22 -!- alimon(~alimon@187.156.103.195) has joined #tryton
2011-06-13 19:10 -!- gremly(~gremly@200.106.202.91) has joined #tryton
2011-06-13 20:09 -!- sharoon(~sharoon@173-9-190-185-miami.txt.hfc.comcastbusiness.net) has joined #tryton
2011-06-13 20:11 <sharoon> cedk: ping
2011-06-13 20:12 <cedk> sharoon: pong
2011-06-13 20:13 <sharoon> cedk: do you have amin to discuss about sequences
2011-06-13 20:14 <sharoon> cedk: 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 ?
2011-06-13 20:15 <cedk> sharoon: I must be in the transaction to ensure to not have duplicates
2011-06-13 20:17 <sharoon> cedk: is there no way to avoid duplicates ?
2011-06-13 20:17 <cedk> sharoon: what is the problem?
2011-06-13 20:18 <sharoon> cedk: for heavy volume systems the most common reason for transaction errors is the sequence
2011-06-13 20:18 <sharoon> cedk: just trying to find a way outside it
2011-06-13 20:19 <cedk> sharoon: what do you call heavy volume?
2011-06-13 20:19 -!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton
2011-06-13 20:19 <sharoon> cedk: many simultaneous transactions
2011-06-13 20:19 <sharoon> cedk: (not read) but write transactions
2011-06-13 20:19 <cedk> sharoon: which transaction from where?
2011-06-13 20:20 <sharoon> cedk: both direct python and also over the client (through dispatcher)
2011-06-13 20:22 <cedk> sharoon: but what is required sequences?
2011-06-13 20:27 <sharoon> cedk: there is no constraint on gap
2011-06-13 20:28 <sharoon> cedk: we dont have problem with gaps (infact its desired0
2011-06-13 20:28 <cedk> sharoon: ok but which Models are created on heavy load and require sequence?
2011-06-13 20:29 <sharoon> cedk: sale.sale, account.invoice, stock.invoice.out
2011-06-13 20:29 <sharoon> *stock.shipment.out
2011-06-13 20:30 <cedk> sharoon: I try to understand, how many sale do you have?
2011-06-13 20:31 <sharoon> cedk: on private chat
2011-06-13 20:32 <cedk> sharoon: ok it comes from website
2011-06-13 20:33 <cedk> sharoon: you should not run the workflow on the fly for website orders
2011-06-13 20:35 <sharoon> cedk: ok
2011-06-13 20:36 <sharoon> cedk: At the moment i have a workaround which is using rabbit mq and celery which reattempts the workflow change. on transaction rserialisation error, it reattempts
2011-06-13 20:38 <cedk> sharoon: I think a webshop should not create sale order but directly shipment and invoice
2011-06-13 20:39 <cedk> sharoon: and indeed not directly those records but should post to a order queue and let the system process them when it has time
2011-06-13 20:39 <cedk> it is the only good way to get good perf
2011-06-13 20:39 <sharoon> cedk: thats how it is done, but that works like a bottleneck because it truly does it one after the other
2011-06-13 20:39 <cedk> which is almost what you did with the mq
2011-06-13 20:40 <cedk> sharoon: a bottleneck for what?
2011-06-13 20:41 <sharoon> cedk: bottleneck for processing during high transaction times of course
2011-06-13 20:41 <cedk> sharoon: don't understand
2011-06-13 20:41 <cedk> sharoon: if there is a queue there is no bottleneck
2011-06-13 20:42 <bechamel> maybe the queue gets bigger and bigger
2011-06-13 20:42 -!- meanmicio(bec3320f@gateway/web/freenode/ip.190.195.50.15) has joined #tryton
2011-06-13 20:43 <meanmicio> happy to announce that the medical kernel data model port is done.
2011-06-13 20:43 <cedk> meanmicio: great
2011-06-13 20:43 <meanmicio> in the main module only. Now is time to start with the reports
2011-06-13 20:45 <meanmicio> cedk : 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 formula
2011-06-13 20:47 <meanmicio> cedk : 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.
2011-06-13 20:47 <cedk> meanmicio: ok I will try to find time to test/review it
2011-06-13 20:48 <sharoon> cedk: bechamel: will let you know after the test
2011-06-13 20:48 <cedk> sharoon, bechamel: there is also the possiblilty to make sharding with sequences
2011-06-13 20:49 <meanmicio> brb
2011-06-13 20:49 <bechamel> sharding is webscale ! :D
2011-06-13 20:49 <sharoon> bechamel: cedk: so are we webscale ;) ?
2011-06-13 20:50 <bechamel> cedk: but I don't see what you mean by sharding in this context
2011-06-13 20:50 <cedk> by sharding on sequence, I mean define a business logic per example on sale (shop, warehouse, etc.) and define different sequence on those records
2011-06-13 20:51 <cedk> use those sequences instead of the default one
2011-06-13 20:51 <cedk> and you can add a prefix/suffix on each sequences to make the differences
2011-06-13 20:53 <sharoon> cedk: sorry, it went above my head
2011-06-13 20:53 <bechamel> cedk: good idea
2011-06-13 20:53 <bechamel> cedk: and there is no way to have a better time resolution ? (I mean milli- or micro- seconds)
2011-06-13 20:54 <cedk> bechamel: it is not the problem
2011-06-13 20:54 <cedk> bechamel: the issue is that we are in serialized transaction
2011-06-13 20:54 <sharoon> bechamel: there is patch which improves resoltion (which is not the highest ~= the system clock)
2011-06-13 20:54 <sharoon> s/not/now
2011-06-13 20:56 -!- ciupicri(~ciupicri@81.180.234.249) has joined #tryton
2011-06-13 20:57 <sharoon> cedk: does this solve the problem of transaction serialisation ?
2011-06-13 20:58 <cedk> sharoon: sharding?
2011-06-13 20:58 <sharoon> cedk: yes
2011-06-13 20:58 <cedk> sharoon: partially, it depends on how much you will shard
2011-06-13 20:58 -!- FWiesing(~franz@mail.tryton.at) has joined #tryton
2011-06-13 20:59 <sharoon> cedk: also on a separate note, it is impossible to catch Transaction Serialisation errors generically for all databases (though we have an abstraction of cursor)
2011-06-13 21:00 <sharoon> cedk: one way to do it to catch OpenrationError, but isnt it too general ?
2011-06-13 21:00 <cedk> sharoon: don't know
2011-06-13 21:01 <sharoon> cedk: do you think we can implement a custom exception on the cursor level which is raised instead of the db adaptor specific one ?
2011-06-13 21:01 <cedk> sharoon: don't understand
2011-06-13 21:02 -!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton
2011-06-13 21:03 <sharoon> cedk: 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 backend
2011-06-13 21:03 <sharoon> cedk: if we handle this error anywhere in module code, then we have to import from psycopg2 and then code becomes dependent on a single backend
2011-06-13 21:05 <cedk> sharoon: it is not standard to DB API 2.0
2011-06-13 21:07 <sharoon> cedk: from DB API 2.0 i think OperationalError is a better error to handle ?
2011-06-13 21:07 <sharoon> cedk: and TransactionRollbackError is a subclass of OperationalError
2011-06-13 21:07 <cedk> sharoon: you will catch too much errors
2011-06-13 21:10 <sharoon> cedk: exactly what i thought too
2011-06-13 21:11 <sharoon> cedk: if the cursor api of tryton which anyway is an abstraction) implements some level of abstraction on transaction rollbacks it would have been better
2011-06-13 21:12 <sharoon> cedk: especially from something like a dispatcher catching operationalerror is too much defensive
2011-06-13 21:12 <sharoon> ACTION chacking what django does
2011-06-13 21:13 <sharoon> cedk: https://code.djangoproject.com/browser/django/trunk/django/db/transaction.py#L23
2011-06-13 21:14 <cedk> sharoon: I don'T understand
2011-06-13 21:15 <sharoon> cedk: the transaction error is an abstration over all database transaction errors across all backends (postgres, mysql etc)
2011-06-13 21:15 <sharoon> cedk: 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 sqlite
2011-06-13 21:16 <cedk> sharoon: I don't see that in the link you give and I don't understand what is "transaciton error"
2011-06-13 21:16 <sharoon> cedk: the doc is here
2011-06-13 21:16 <sharoon> https://docs.djangoproject.com/en/dev/topics/db/transactions/
2011-06-13 21:17 <cedk> sharoon: I doesn't explain what is a "transaction error"
2011-06-13 21:19 <sharoon> cedk: it is a very wide abstration - it encapsulates all errors that occur in transaction
2011-06-13 21:19 <cedk> sharoon: like the OperationalError
2011-06-13 21:20 <sharoon> cedk: yes - if openrationerror is only used by the DB API
2011-06-13 21:27 <cedk> sharoon: shoudl check of sqlite and mysql lib has the TransactionRollbackError exception
2011-06-13 21:27 <sharoon> cedk: ok
2011-06-13 21:31 -!- vladimirek(~vladimire@bband-dyn79.178-41-183.t-com.sk) has joined #tryton
2011-06-13 21:43 -!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton
2011-06-13 21:55 -!- alimon(~alimon@201.158.247.118) has joined #tryton
2011-06-13 22:02 -!- saxa(~sasa@189.26.255.43) has joined #tryton
2011-06-13 22:21 <ciupicri> sharkcz, sorry for the bad English in the last comments on the tryton accounting package reviews. It was morning after a pretty long night.
2011-06-13 23:03 -!- cheche(cheche@46.25.80.67) has joined #tryton

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!