IRC logs of #tryton for Thursday, 2010-02-11 #tryton log beginning Thu Feb 11 00:00:02 CET 2010
cedksharoon: SA branch that is developped since 4-5 months00:00
cedksharoon: did you see the last "improvement" of OpenERP00:00
cedksharoon: the grouped list00:01
sharooncedk: saw that00:01
sharooncedk: the layout imprvements look cool BTW00:01
sharooncedk: SA is such a f***ing idea00:01
sharooncedk: framework over a framework ??!@#$%^00:01
cedksharoon: what is cool in the layout ? I find it uggly big buttons, too much functionnality on the same view00:02
cedksharoon: and I still don't understand how the "and" "or" works as there is no parenthesis00:03
sharooncedk: read comment #200:04
sharooncedk: two issue Open ERP may never get over: Rounding trouble & this stupid workflow: (every customer eats my head, these days i have started printing this workflow as a design doc)00:07
cedksharoon: I think this will never happen into Tryton because we choose to have the purchase/sale as the master document that link to others00:09
sharooncedk: i liked that design00:09
cedksharoon: indeed it is linked on lines00:10
cedksharoon: per example the creation of the invoice is always made by the sale, for every kind of invoicing (picking, sale etc)00:10
sharooncedk: and it bounces back on us here again: with the magento erp connector and this was one of the first things i looked at when i reviewed tryton00:11
cedksharoon: so status (delivery, invoice etc) of the sale is always up todate because it is the sale that do the work00:11
cedksharoon: I don't understand why it needs to run the scheduler00:13
sharooncedk: the sale order line will remain at confirmed state till the scheduler runs....00:15
sharoonif (not line.procurement_id) or (line.procurement_id.state=='done'):00:15
sharoonso if there's no procurement_id its ok, eg. services, if its there, then scheduler has to run00:15
cedksharoon: ha yes, it is for the services create task00:16
cedksharoon: I still don't know if it is the right way to handle this00:17
sharooncedk: big boss gave up, so now no alternative, just accept what we have00:17
cedksharoon: I don't understand00:18
cedksharoon: funny, he finds normal that the system makes double lines :-)00:19
sharooncedk: sounds like microsoft to me where bugs are called features00:20
cedksharoon: and must be kept for compatiblity :-)00:21
sharooncedk: compare it to the funny little box where we enter the environment path! god its been like that from the first windows i ever saw00:22
-!- rvalyi(~rvalyi@ has joined #tryton02:14
rvalyiis the Tryton awake?02:15
rvalyiwas a random test actually, will start investigating at Tryton myself as some people I trust recommend it to me...02:15
-!- ikks_(~ikks@ has joined #tryton03:03
-!- rednul_( has joined #tryton03:09
-!- arrakis(~arrakis@ has joined #tryton04:50
-!- yangoon( has joined #tryton05:18
-!- rvalyi(~rvalyi@ has left #tryton05:52
-!- arrakis( has joined #tryton06:01
-!- vengfulsquirrel( has joined #tryton06:42
-!- mfladischer(~fladische@2001:5c0:1505:7e00:34c9:a7ff:fecc:2660) has joined #tryton07:34
-!- Timitos(~timitos@ has joined #tryton07:58
-!- sharoon( has joined #tryton08:34
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:52
-!- fil( has joined #tryton08:58
-!- paepke( has joined #tryton09:02
-!- enlightx( has joined #tryton09:09
-!- yangoon( has joined #tryton09:09
-!- bechamel( has joined #tryton09:27
-!- paepke_( has joined #tryton09:40
-!- paepke__( has joined #tryton09:54
-!- ikks_(~ikks@ has joined #tryton11:36
sharooncedk: bechamel: is browse method not callable via xml-rpc?13:19
sharooncedk: bechamel: it returns Calling method browse on model is not allowed!13:19
bechamelsharoon: no13:19
cedksharoon: it is logical, BrowseRecord are python object13:20
bechamelsharoon: xmlrpc support CRUD: read, write, create, delete13:20
cedksharoon: they are not translatable into XML-RPC13:20
sharooncedk: bechamel: ok13:20
bechamelsharoon: and some extra13:21
sharooncedk: bechamel: also with tryton as a module i think i am getting an issue... it's locking records i think13:21
sharoonTransactionRollbackError: could not serialize access due to concurrent update13:21
sharoonCONTEXT:  SQL statement "SELECT 1 FROM ONLY "public"."account_account" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"13:21
sharooncedk: bechamel: any thoughts?13:22
bechamelsharoon: what are you doing ?13:23
cedksharoon: who is doing this query?13:23
sharooncedk: bechamel: the query is done from a django module, which called invoice_print13:24
sharooncedk: bechamel:
cedksharoon: it is clear, you have something that update the record in parallel13:27
sharooncedk: issue resolved, when i changed to multi = true in config13:27
cedksharoon: multi=true is only for the cache to be clean13:28
sharooncedk: but not sure how it resolved this issue?13:28
cedksharoon: concurrent update may always happens in concurrency environment13:30
sharooncedk: ok13:30
sharooncedk: i think it could be this issue13:30
cedksharoon: you can simply try to not update too much at once to limit the possibility13:30
sharooncedk: ok13:30
cedksharoon: tryton use serial transaction mode because it requires to read data from a coherent state13:31
cedksharoon: but I seems that django read data with FOR SHARE clause which looks the rows13:32
sharooncedk: when opened as a module, does cursor get closed automatically or do we need to close manually?13:33
sharooncedk: what happens if many cursors exist?13:33
cedksharoon: don't understand13:33
sharooncedk: we open a db cursor when tryton is used as a module.13:34
cedksharoon: you are responsible of the cursor13:35
sharooncedk: looks like thats the issue here13:35
sharooncedk: too many open cursors13:35
cedksharoon: not sure13:36
cedksharoon: do you have django accessing directly the DB?13:36
sharooncedk: no13:36
sharooncedk: it accesses through the browse object13:37
cedksharoon: so I don't know from where the FOR UPDATE clause comes13:37
cedksharoon: we don't use it in Tryton13:37
sharooncedk: neither me, not sure13:37
cedksharoon: perhaps an internal pg stuff because of the serial transaction mode13:38
sharooncedk: possible13:39
cedksharoon: so leaving too much open cursors may be the issue13:42
cedksharoon: because locks are kept until commit13:42
sharooncedk: thinking of a possible way to close it13:42
sharooncedk: is there a timeout on cursors?13:43
cedksharoon: cursor.close()13:51
sharooncedk: we need to update the tryton as a module tutorial to say that the cursor has to be managed13:58
-!- g0q(~g0q@ has joined #tryton14:18
cedksharoon: ok, feel free to update14:19
-!- enlightx( has joined #tryton14:23
-!- g0q(~g0q@ has left #tryton15:20
-!- juanfer(~juanfer@ has joined #tryton15:27
-!- mlhamel(~quassel@2607:fad8:4:0:222:19ff:fedf:7cd0) has joined #tryton15:30
-!- petrus(~petrus@ has joined #tryton17:46
-!- rednul_( has joined #tryton17:49
-!- FWiesing( has joined #tryton18:18
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton19:17
-!- woakas(~woakas@ has joined #tryton19:33
-!- vengfulsquirrel( has joined #tryton19:50
-!- sharoon( has joined #tryton20:10
-!- sharkcz( has joined #tryton20:10
-!- tekknokrat( has joined #tryton20:19
-!- LucaSub1( has joined #tryton20:27
-!- LucaSub1( has left #tryton20:28
-!- juanfer(~juanfer@ has joined #tryton21:23
-!- vengfulsquirrel( has joined #tryton22:08
-!- paepke( has joined #tryton22:51

Generated by 2.11.0 by Marius Gedminas - find it at!