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

chat.freenode.net #tryton log beginning Thu Jan 8 00:00:01 CET 2015
2015-01-08 00:07 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2015-01-08 00:14 -!- newzen1(~newzen@201.242.159.40) has joined #tryton
2015-01-08 02:11 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2015-01-08 02:25 -!- smarro(~sebastian@190.105.93.196) has joined #tryton
2015-01-08 04:38 -!- trytry(~william@203-114-166-118.dsl.sta.inspire.net.nz) has joined #tryton
2015-01-08 06:01 -!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton
2015-01-08 06:01 -!- yangoon(~mathiasb@p549F272B.dip0.t-ipconnect.de) has joined #tryton
2015-01-08 06:04 -!- TheCowboy(~TheCowboy@ip68-98-183-236.dc.dc.cox.net) has joined #tryton
2015-01-08 06:20 -!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton
2015-01-08 06:38 -!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton
2015-01-08 06:52 -!- apostatize(~visavis@gateway/vpn/privateinternetaccess/apostatize) has joined #tryton
2015-01-08 07:23 -!- ronaldm(~ronaldm@197.211.216.214) has joined #tryton
2015-01-08 07:26 -!- mar(~marius@v100.nfq.lt) has joined #tryton
2015-01-08 07:31 -!- pobsteta(~Thunderbi@4cb54-3-88-160-87-54.fbx.proxad.net) has joined #tryton
2015-01-08 07:35 -!- trytry(~william@203-114-166-118.dsl.sta.inspire.net.nz) has joined #tryton
2015-01-08 08:42 -!- Timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton
2015-01-08 08:46 -!- trytry(~william@203-114-166-118.dsl.sta.inspire.net.nz) has joined #tryton
2015-01-08 09:02 <mar> there's still some issue with caching in 3.4 :/
2015-01-08 09:02 <mar> caching + history + ir.property
2015-01-08 09:23 -!- ytz(~textual@opfw01.options-it.com) has joined #tryton
2015-01-08 09:30 <mar> https://bugs.tryton.org/issue4463
2015-01-08 09:31 -!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton
2015-01-08 09:41 -!- bechamel(~Adium@host-85-201-213-94.dynamic.voo.be) has joined #tryton
2015-01-08 10:03 -!- buxy(~rhertzog@mail.vm.ouaza.com) has joined #tryton
2015-01-08 10:08 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2015-01-08 10:12 -!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton
2015-01-08 10:23 <mar> cedk, can you help me solve issue4463?
2015-01-08 10:24 <mar> there are few problems with http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1121 i believe
2015-01-08 10:25 <pokoli> mar: what are those problems?
2015-01-08 10:25 <mar> 1) it should be columns[:3] instead of [:2], because __id is not fetched?
2015-01-08 10:26 <mar> 2) cache update should be moved below len(rows) >= cursor.IN_MAX
2015-01-08 10:26 <mar> __id is not fetched because of _timestamp I believe
2015-01-08 10:27 <mar> http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1049
2015-01-08 10:28 <pokoli> mar: __id is added on line 1039
2015-01-08 10:29 <mar> nope, i'm wrong. colums = ["id", "_datetime", "__id", ...] at least in my case
2015-01-08 10:29 <pokoli> mar: but it's only fetched when you have a _datetime set in the context
2015-01-08 10:29 <mar> yes
2015-01-08 10:29 <mar> filter_history required __id field
2015-01-08 10:30 <mar> and column[:2] == ["id", "_datetime"]
2015-01-08 10:30 <mar> *columns
2015-01-08 10:30 <mar> so line 1131 fails
2015-01-08 10:31 <pokoli> mar: i see that there is a return on filter_history when table has no history os there is no datetime in context
2015-01-08 10:31 <pokoli> mar: so I don't see any problem there
2015-01-08 10:32 <mar> pokoli, i'm trying to solve a case when datetime is in context
2015-01-08 10:33 <pokoli> mar: if no datetime in the context it returns here http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1067
2015-01-08 10:33 <pokoli> mar: and the data is read for the main table (not from the history one)
2015-01-08 10:34 <mar> pokoli, there *IS* _datetime in context
2015-01-08 10:34 <pokoli> mar: sorry, but if there is _datetime in the context __id is also fetched
2015-01-08 10:35 <mar> pokoli, fetched in first query (with limit cursor.IN_MAX)
2015-01-08 10:35 <mar> but on http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1128
2015-01-08 10:35 <mar> it uses columns[:2] which strips __id
2015-01-08 10:35 <mar> and filter_history then fails with KeyError
2015-01-08 10:35 <mar> I dumped columns on chat IN_MAX case, and it's
2015-01-08 10:36 <mar> http://paste2.org/XAD5Phej
2015-01-08 10:36 <mar> so that's why I think it should be :3 insted of :2
2015-01-08 10:36 <pokoli> mar: that makes sense for me
2015-01-08 10:37 <mar> ok, lets move to 2)
2015-01-08 10:37 <mar> http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1102 filters history entries
2015-01-08 10:38 <mar> and http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1121 doesn't get executed in case of count(rows) == cursor.IN_MAX
2015-01-08 10:39 <mar> doen't get executed because filter_history filters the rows, and makes rows = [] at least in my case
2015-01-08 10:39 <pokoli> mar: it's related to http://hg.tryton.org/trytond/rev/a2b4dfda2f51 , as __id where introduced but columns[:2] didn't change
2015-01-08 10:40 <mar> do I create separate issue for it?
2015-01-08 10:41 <pokoli> mar: 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 :P
2015-01-08 10:42 <pokoli> mar: the only reason i see to filter_history to make rows = [] is that the record didn't exist on that timestamp
2015-01-08 10:42 <pokoli> mar: can you elaborate in this way?
2015-01-08 10:45 <mar> pokoli, products by location fetches history for many res_ids at once
2015-01-08 10:45 <mar> because it fetches only 1000 rows, it fails to find appropriate history entry for some products
2015-01-08 10:45 <mar> and cost_value becomes None
2015-01-08 10:46 <mar> but the record actually exists
2015-01-08 10:47 <mar> and if I increase cursor.IN_MAX to a bigger value, it finds it with the same query
2015-01-08 10:48 <mar> so I believe history filtering should be done after cursor.IN_MAX == len(rows) check
2015-01-08 10:49 <pokoli> mar: i belive the problem is the limit
2015-01-08 10:50 <mar> are you suggesting not limiting query by cursor.IN_MAX in _history case?
2015-01-08 10:51 <pokoli> mar: that may solve the problem, but i think it's not the right solution
2015-01-08 10:52 <mar> what do you think the right solution is?
2015-01-08 10:52 <pokoli> mar: don't know
2015-01-08 10:53 <mar> do you agree with this: so I believe history filtering should be done after cursor.IN_MAX == len(rows) check
2015-01-08 10:53 <mar> ?
2015-01-08 10:54 <cedk> mar: yes the check should be done before the first filter_history
2015-01-08 10:54 <mar> what about caching?
2015-01-08 10:54 <cedk> we need tests case with len(records) > in_max
2015-01-08 10:54 <cedk> mar: just the test
2015-01-08 10:55 <mar> I believe
2015-01-08 10:55 <mar> http://hg.tryton.org/trytond/file/b87a8f3582ee/trytond/model/modelsql.py#l1104
2015-01-08 10:56 <mar> should also be done after len(records) >= in_max case.
2015-01-08 10:58 <cedk> mar: no need to believe but writing tests
2015-01-08 11:16 -!- nicoe(~nicoe@2a02:a03f:308c:7700:ee55:f9ff:fe7b:f7ac) has joined #tryton
2015-01-08 11:34 <pokoli> mar: I agree with ced that it will be easier with a test, so we can reproduce the issue :)
2015-01-08 11:39 -!- ronaldm(~ronaldm@197.211.216.214) has joined #tryton
2015-01-08 11:39 <mar> ok I'll try it
2015-01-08 11:44 -!- bechamel1(~Adium@host-85-201-213-94.dynamic.voo.be) has joined #tryton
2015-01-08 11:45 -!- lfm(~meanmicio@177.Red-83-47-20.dynamicIP.rima-tde.net) has joined #tryton
2015-01-08 12:01 <mar> cedk, http://codereview.tryton.org/10031002
2015-01-08 12:10 <pokoli> mar: adding and order by on create date fixed the problem for me
2015-01-08 12:12 <pokoli> mar: http://pastebin.com/yu9YP6MA
2015-01-08 12:14 -!- smarro(~sebastian@190.105.93.196) has joined #tryton
2015-01-08 12:49 <mar> pokoli, it helps for performance
2015-01-08 12:49 <mar> but doesn't fix the actual problem
2015-01-08 12:50 <pokoli> mar: but on your database you have a lot of records with more than one history record for it, isn't it?
2015-01-08 12:56 <mar> yes
2015-01-08 12:58 <pokoli> mar: so you should create another test that replicates your scenario
2015-01-08 12:58 <mar> ok
2015-01-08 12:58 <pokoli> mar: for me it's good to keep the current one also
2015-01-08 12:59 <mar> i'll just try fixing issues in review comments
2015-01-08 13:04 <mar> ok, done
2015-01-08 13:13 <cedk> pokoli, mar: yes both cases should be tested because they have 2 paths
2015-01-08 13:18 -!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton
2015-01-08 13:24 -!- kstenger(~karla@200.124.209.158) has joined #tryton
2015-01-08 13:46 <mar> pokoli, added another testcase
2015-01-08 14:01 -!- mariomop(~quassel@host245.186-125-105.telecom.net.ar) has joined #tryton
2015-01-08 14:13 -!- pobsteta(~Thunderbi@ANancy-653-1-611-65.w109-221.abo.wanadoo.fr) has joined #tryton
2015-01-08 14:18 -!- pablovannini(~pablo@host126.186-109-85.telecom.net.ar) has joined #tryton
2015-01-08 14:39 -!- yangoon(~mathiasb@p549F272B.dip0.t-ipconnect.de) has joined #tryton
2015-01-08 14:54 -!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has joined #tryton
2015-01-08 14:56 -!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has joined #tryton
2015-01-08 14:57 -!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has left #tryton
2015-01-08 14:58 -!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has joined #tryton
2015-01-08 14:58 -!- pablovannini(~pablo@host126.186-109-85.telecom.net.ar) has joined #tryton
2015-01-08 16:04 <mar> what would correct indent for this:
2015-01-08 16:04 <mar> http://codereview.tryton.org/10031002/diff/60004/trytond/tests/test_history.py#newcode390
2015-01-08 16:04 <mar> ?
2015-01-08 16:04 <mar> *what would correct indent be?
2015-01-08 16:04 <mar> \ \n as transaction?
2015-01-08 16:05 <pokoli> mar: line 390 must be two idents inner of the line 389
2015-01-08 16:06 <pokoli> mar: http://pastebin.com/thZdK9gH
2015-01-08 16:06 <mar> doesn't bracket rule apply?
2015-01-08 16:08 <pokoli> mar: no brackets in python :)
2015-01-08 16:08 <mar> pokoli, can you think of a way how to solve cache issue?
2015-01-08 16:09 <mar> caching wrong data (when len(rows) > IN_MAX) produces wrong results
2015-01-08 16:09 <pokoli> mar: https://code.google.com/p/tryton/wiki/CodingGuidelines
2015-01-08 16:11 <pokoli> mar: for what you're saying I understant that the problem is about reading wrong data, caching doesn't mind
2015-01-08 16:12 <pokoli> mar: as if you read the right data, it will be correctly cached, so the problem is not about cache
2015-01-08 16:16 <cedk> pokoli, mar: all this conversation should be replicated on the issue (at least a summary)
2015-01-08 16:17 <pokoli> cedk: a link to the irclog is enough?
2015-01-08 16:19 -!- smarro(~sebastian@181.47.135.16) has joined #tryton
2015-01-08 16:19 <cedk> pokoli: I don't find
2015-01-08 16:53 -!- pobsteta(~Thunderbi@4cb54-3-88-160-87-54.fbx.proxad.net) has joined #tryton
2015-01-08 17:04 -!- lfm(~meanmicio@177.Red-83-47-20.dynamicIP.rima-tde.net) has joined #tryton
2015-01-08 17:05 -!- meanmicio(~meanmicio@177.Red-83-47-20.dynamicIP.rima-tde.net) has joined #tryton
2015-01-08 17:05 -!- meanmicio(~meanmicio@fsf/member/meanmicio) has joined #tryton
2015-01-08 17:10 -!- notzippy(~sabayonus@d207-216-251-90.bchsia.telus.net) has joined #tryton
2015-01-08 17:30 <mar> cedk, can you explain what you meant with http://codereview.tryton.org/10031002/diff/2/trytond/model/modelsql.py#newcode1084
2015-01-08 17:31 <cedk> mar: you already did
2015-01-08 17:31 <mar> how about http://codereview.tryton.org/10031002/diff/110001/trytond/model/modelsql.py#newcode1084 then?
2015-01-08 17:33 <mar> because I think cache should be just before cls.browse
2015-01-08 17:34 <mar> if you don't want to disable it
2015-01-08 17:34 <mar> currently it doesn't cache in that case anyway
2015-01-08 17:38 <cedk> mar: it doesn't cache
2015-01-08 17:45 <mar> so can I move it down?
2015-01-08 18:06 -!- Telesight(~anthony@4daedff9.ftth.telfortglasvezel.nl) has joined #tryton
2015-01-08 18:35 -!- plantian(~ian@174-134-217-28.res.bhn.net) has joined #tryton
2015-01-08 19:17 -!- prksh(~prksh@101.0.57.107) has joined #tryton
2015-01-08 19:49 -!- prksh(~prksh@101.0.57.107) has left #tryton
2015-01-08 20:15 -!- gremly(~gremly@190.85.36.58) has joined #tryton
2015-01-08 20:30 -!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has left #tryton
2015-01-08 20:34 -!- jcros(~Thunderbi@251.171.125.78.rev.sfr.net) has joined #tryton
2015-01-08 20:50 -!- pjstevns(~Thunderbi@2001:981:7170:1:f803:7d4:d37a:ba14) has joined #tryton
2015-01-08 21:20 -!- smarro(~sebastian@190.105.93.196) has joined #tryton
2015-01-08 21:23 -!- hiaselhans(~Thunderbi@178.115.132.107.wireless.dyn.drei.com) has joined #tryton
2015-01-08 21:47 -!- pablovannini(~pablo@host126.186-109-85.telecom.net.ar) has left #tryton
2015-01-08 22:22 -!- ytz(~textual@05418a46.skybroadband.com) has joined #tryton
2015-01-08 22:29 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton
2015-01-08 23:05 <plantian> Anyone 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 ?
2015-01-08 23:07 <cedk> plantian: what do you call "client timing out"?
2015-01-08 23:24 <plantian> cedk: 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.
2015-01-08 23:25 <cedk> it is probably fixed with issue4398
2015-01-08 23:26 <cedk> plantian: it is the timeout of the socket, not the application
2015-01-08 23:26 <cedk> it happens when you go throught aggresive firewall
2015-01-08 23:28 <plantian> cedk: It is weird it never happened before until the user upgraded their computer to OS X Yosemite.
2015-01-08 23:31 <plantian> Is that patch backported to 2.8?
2015-01-08 23:31 <cedk> plantian: no
2015-01-08 23:50 <plantian> ha okay, how hard do you think it will be to upgrade from 2.8 to 3.4 ?

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