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/!