IRC logs of #tryton for Thursday, 2015-01-08

chat.freenode.net #tryton log beginning Thu Jan 8 00:00:01 CET 2015
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton00:07
-!- newzen1(~newzen@201.242.159.40) has joined #tryton00:14
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton02:11
-!- smarro(~sebastian@190.105.93.196) has joined #tryton02:25
-!- trytry(~william@203-114-166-118.dsl.sta.inspire.net.nz) has joined #tryton04:38
-!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton06:01
-!- yangoon(~mathiasb@p549F272B.dip0.t-ipconnect.de) has joined #tryton06:01
-!- TheCowboy(~TheCowboy@ip68-98-183-236.dc.dc.cox.net) has joined #tryton06:04
-!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton06:20
-!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton06:38
-!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton06:52
-!- ronaldm(~ronaldm@197.211.216.214) has joined #tryton07:23
-!- mar(~marius@v100.nfq.lt) has joined #tryton07:26
-!- pobsteta(~Thunderbi@4cb54-3-88-160-87-54.fbx.proxad.net) has joined #tryton07:31
-!- trytry(~william@203-114-166-118.dsl.sta.inspire.net.nz) has joined #tryton07:35
-!- Timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton08:42
-!- trytry(~william@203-114-166-118.dsl.sta.inspire.net.nz) has joined #tryton08:46
marthere's still some issue with caching in 3.4 :/09:02
marcaching + history + ir.property09:02
-!- ytz(~textual@opfw01.options-it.com) has joined #tryton09:23
marhttps://bugs.tryton.org/issue446309:30
-!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton09:31
-!- bechamel(~Adium@host-85-201-213-94.dynamic.voo.be) has joined #tryton09:41
-!- buxy(~rhertzog@mail.vm.ouaza.com) has joined #tryton10:03
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton10:08
-!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton10:12
marcedk, can you help me solve issue4463?10:23
marthere are few problems with http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1121 i believe10:24
pokolimar: what are those problems?10:25
mar1) it should be columns[:3] instead of [:2], because __id is not fetched?10:25
mar2) cache update should be moved below len(rows) >= cursor.IN_MAX10:26
mar__id is not fetched because of _timestamp I believe10:26
marhttp://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l104910:27
pokolimar: __id is added on line 103910:28
marnope, i'm wrong. colums = ["id", "_datetime", "__id", ...] at least in my case10:29
pokolimar: but it's only fetched when you have a _datetime set in the context10:29
maryes10:29
marfilter_history required __id field10:29
marand column[:2] == ["id", "_datetime"]10:30
mar*columns10:30
marso line 1131 fails10:30
pokolimar: i see that there is a return on filter_history when table has no history os there is no datetime in context10:31
pokolimar: so I don't see any problem there10:31
marpokoli, i'm trying to solve a case when datetime is in context10:32
pokolimar: if no datetime in the context it returns here http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l106710:33
pokolimar: and the data is read for the main table (not from the history one)10:33
marpokoli, there *IS* _datetime in context10:34
pokolimar: sorry, but if there is _datetime in the context __id is also fetched10:34
marpokoli, fetched in first query (with limit cursor.IN_MAX)10:35
marbut on http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l112810:35
marit uses columns[:2] which strips __id10:35
marand filter_history then fails with KeyError10:35
marI dumped columns on chat IN_MAX case, and it's10:35
marhttp://paste2.org/XAD5Phej10:36
marso that's why I think it should be :3 insted of :210:36
pokolimar: that makes sense for me10:36
marok, lets move to 2)10:37
marhttp://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1102 filters history entries10:37
marand http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1121 doesn't get executed in case of count(rows) == cursor.IN_MAX10:38
mardoen't get executed because filter_history filters the rows, and makes rows = [] at least in my case10:39
pokolimar: it's related to http://hg.tryton.org/trytond/rev/a2b4dfda2f51 , as __id where introduced but columns[:2] didn't change10:39
mardo I create separate issue for it?10:40
pokolimar:  for me it's enought to clarify in the current issue :) it's easier for others to review if we have all the info available :P10:41
pokolimar: the only reason i see to filter_history to make rows = [] is that the record didn't exist on that timestamp10:42
pokolimar: can you elaborate in this way?10:42
marpokoli, products by location fetches history for many res_ids at once10:45
marbecause it fetches only 1000 rows, it fails to find appropriate history entry for some products10:45
marand cost_value becomes None10:45
marbut the record actually exists10:46
marand if I increase cursor.IN_MAX to a bigger value, it finds it with the same query10:47
marso I believe history filtering should be done after cursor.IN_MAX == len(rows) check10:48
pokolimar: i belive the problem is the limit10:49
marare you suggesting not limiting query by cursor.IN_MAX in _history case?10:50
pokolimar: that may solve the problem, but i think it's not the right solution10:51
marwhat do you think the right solution is?10:52
pokolimar: don't know10:52
mardo you agree with this: so I believe history filtering should be done after cursor.IN_MAX == len(rows) check10:53
mar?10:53
cedkmar: yes the check should be done before the first filter_history10:54
marwhat about caching?10:54
cedkwe need tests case with len(records) > in_max10:54
cedkmar: just the test10:54
marI believe10:55
marhttp://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l110410:55
marshould also be done after len(records) >= in_max case.10:56
cedkmar: no need to believe but writing tests10:58
-!- nicoe(~nicoe@2a02:a03f:308c:7700:ee55:f9ff:fe7b:f7ac) has joined #tryton11:16
pokolimar: I agree with ced that it will be easier with a test, so we can reproduce the issue :)11:34
-!- ronaldm(~ronaldm@197.211.216.214) has joined #tryton11:39
marok I'll try it11:39
-!- bechamel1(~Adium@host-85-201-213-94.dynamic.voo.be) has joined #tryton11:44
-!- lfm(~meanmicio@177.Red-83-47-20.dynamicIP.rima-tde.net) has joined #tryton11:45
marcedk, http://codereview.tryton.org/1003100212:01
pokolimar: adding and order by on create date fixed the problem for me12:10
pokolimar: http://pastebin.com/yu9YP6MA12:12
-!- smarro(~sebastian@190.105.93.196) has joined #tryton12:14
marpokoli, it helps for performance12:49
marbut doesn't fix the actual problem12:49
pokolimar: but on your database you have a lot of records with more than one history record for it, isn't it?12:50
maryes12:56
pokolimar: so you should create another test that replicates your scenario12:58
marok12:58
pokolimar: for me it's good to keep the current one also12:58
mari'll just try fixing issues in review comments12:59
marok, done13:04
cedkpokoli, mar: yes both cases should be tested because they have 2 paths13:13
-!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton13:18
-!- kstenger(~karla@200.124.209.158) has joined #tryton13:24
marpokoli, added another testcase13:46
-!- mariomop(~quassel@host245.186-125-105.telecom.net.ar) has joined #tryton14:01
-!- pobsteta(~Thunderbi@ANancy-653-1-611-65.w109-221.abo.wanadoo.fr) has joined #tryton14:13
-!- pablovannini(~pablo@host126.186-109-85.telecom.net.ar) has joined #tryton14:18
-!- yangoon(~mathiasb@p549F272B.dip0.t-ipconnect.de) has joined #tryton14:39
-!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has joined #tryton14:54
-!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has joined #tryton14:56
-!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has left #tryton14:57
-!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has joined #tryton14:58
-!- pablovannini(~pablo@host126.186-109-85.telecom.net.ar) has joined #tryton14:58
marwhat would correct indent for this:16:04
marhttp://codereview.tryton.org/10031002/diff/60004/trytond/tests/test_history.py#newcode39016:04
mar?16:04
mar*what would correct indent be?16:04
mar\ \n as transaction?16:04
pokolimar: line 390 must be two idents inner of the line 38916:05
pokolimar: http://pastebin.com/thZdK9gH16:06
mardoesn't bracket rule apply?16:06
pokolimar: no brackets in python :)16:08
marpokoli, can you think of a way how to solve cache issue?16:08
marcaching wrong data (when len(rows) > IN_MAX) produces wrong results16:09
pokolimar: https://code.google.com/p/tryton/wiki/CodingGuidelines16:09
pokolimar: for what you're saying I understant that the problem is about reading wrong data, caching doesn't mind16:11
pokolimar: as if you read the right data, it will be correctly cached, so the problem is not about cache16:12
cedkpokoli, mar: all this conversation should be replicated on the issue (at least a summary)16:16
pokolicedk: a link to the irclog is enough?16:17
-!- smarro(~sebastian@181.47.135.16) has joined #tryton16:19
cedkpokoli: I don't find16:19
-!- pobsteta(~Thunderbi@4cb54-3-88-160-87-54.fbx.proxad.net) has joined #tryton16:53
-!- lfm(~meanmicio@177.Red-83-47-20.dynamicIP.rima-tde.net) has joined #tryton17:04
-!- meanmicio(~meanmicio@177.Red-83-47-20.dynamicIP.rima-tde.net) has joined #tryton17:05
-!- meanmicio(~meanmicio@fsf/member/meanmicio) has joined #tryton17:05
-!- notzippy(~sabayonus@d207-216-251-90.bchsia.telus.net) has joined #tryton17:10
marcedk, can you explain what you meant with http://codereview.tryton.org/10031002/diff/2/trytond/model/modelsql.py#newcode108417:30
cedkmar: you already did17:31
marhow about http://codereview.tryton.org/10031002/diff/110001/trytond/model/modelsql.py#newcode1084 then?17:31
marbecause I think cache should be just before cls.browse17:33
marif you don't want to disable it17:34
marcurrently it doesn't cache in that case anyway17:34
cedkmar: it doesn't cache17:38
marso can I move it down?17:45
-!- Telesight(~anthony@4daedff9.ftth.telfortglasvezel.nl) has joined #tryton18:06
-!- plantian(~ian@174-134-217-28.res.bhn.net) has joined #tryton18:35
-!- prksh(~prksh@101.0.57.107) has joined #tryton19:17
-!- prksh(~prksh@101.0.57.107) has left #tryton19:49
-!- gremly(~gremly@190.85.36.58) has joined #tryton20:15
-!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has left #tryton20:30
-!- jcros(~Thunderbi@251.171.125.78.rev.sfr.net) has joined #tryton20:34
-!- pjstevns(~Thunderbi@2001:981:7170:1:f803:7d4:d37a:ba14) has joined #tryton20:50
-!- smarro(~sebastian@190.105.93.196) has joined #tryton21:20
-!- hiaselhans(~Thunderbi@178.115.132.107.wireless.dyn.drei.com) has joined #tryton21:23
-!- pablovannini(~pablo@host126.186-109-85.telecom.net.ar) has left #tryton21:47
-!- ytz(~textual@05418a46.skybroadband.com) has joined #tryton22:22
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton22:29
plantianAnyone have any thoughts on my issue about the client timing out in 6 minutes but the server side timeout is 4 hours in tryton 2.8 ?23:05
cedkplantian: what do you call "client timing out"?23:07
plantiancedk: The user said something about error 8 and the message mentioned a timeout but I'm having the user try letting the client idle to try to trigger message again.23:24
cedkit is probably fixed with issue439823:25
cedkplantian: it is the timeout of the socket, not the application23:26
cedkit happens when you go throught aggresive firewall23:26
plantiancedk: It is weird it never happened before until the user upgraded their computer to OS X Yosemite.23:28
plantianIs that patch backported to 2.8?23:31
cedkplantian: no23:31
plantianha okay, how hard do you think it will be to upgrade from 2.8 to 3.4 ?23:50

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