IRC logs of #tryton for Friday, 2013-09-06

chat.freenode.net #tryton log beginning Fri Sep 6 00:00:02 CEST 2013
HeBDwhere can i find the release scheduel for the next version of tryton?03:49
PilouHeBD: See http://www.tryton.org/events.html07:23
HeBD6 weeks to 3.0 should i learn to use 2.8 or wait for 3.0? is there a beta version of 3.0 i can try?07:27
Pilouand http://code.google.com/p/tryton/wiki/ReleaseGeneral (there is a major release every six months)07:27
HeBDthe wiki links to http://www.tryton.org/community/calendar.html for release dates :(07:28
Piloudon't wait :) demo server (http://www.tryton.org/download.html#demo) use 2.8, but you could easily try the trunk07:33
-!- vernicho1(~Thunderbi@gex01-1-78-234-55-95.fbx.proxad.net) has left #tryton07:38
HeBDok thanks07:39
-!- priyankarani(~priyanka@122.177.85.209) has left #tryton07:39
jvblascomorning everyone11:02
jeancavallojvblasco: morning11:02
jvblascohow do i add methods to the RPC interface with write permissions? i always get the same error: http://pastebin.com/qCrLaE1C13:25
jvblascoi already tried with the admin user and with: with Transaction().set_user(0, set_context=True):13:25
jvblascoand this is the code i use to add the methods in the RPC interface: http://pastebin.com/9aRzLETD13:28
jvblascoi'm starting to run out of ideas13:28
jeancavallojvblasco: the RPC class __init__ method has a readonly parameter13:29
jeancavallojvblasco: http://hg.tryton.org/trytond/file/5bd1e13ab72d/trytond/rpc.py#l1713:30
jeancavallojvblasco: So in your cls.__rpc__.update use RPC(readonly=False) should do the trick13:30
jvblascojeancavallo: YEAH! that did the trick. Didn't know that the RPC had readonly=true by default. Thnx so much man ;)13:33
jeancavallojvblasco: you're welcome :) Took some time to figure this one out the first time :)13:34
-!- priyankarani(~priyanka@122.177.85.209) has left #tryton14:09
sharoonthomascedk: we once discussed about improving the current trytond.cache.Cache with a possibility to use something like memcached15:35
sharoonthomascedk: is that on the roadmap ? would you be interested to have such an improvement ?15:36
cedksharoonthomas: I don't know15:37
cedksharoonthomas: indeed I don't see how it could work15:37
sharoonthomascedk: I think we could have subclasses of trytond.cache.Cache which change the get and set methods to work with different caching backends ?15:38
sharoonthomascedk: do we cache objects which cannot be serialized/pickled ?15:38
cedksharoonthomas: no and indeed, we should try to never cache anything15:39
sharoonthomascedk: i did not understand the last part, could you elaborate please ?15:40
cedksharoonthomas: http://martinfowler.com/bliki/TwoHardThings.html15:42
sharoonthomascedk: invalidation ?15:42
cedksharoonthomas: better to not use it15:44
sharoonthomascedk: with our kind of relational system invalidation may need to be done for a change in any model15:44
sharoonthomascedk: but there are performance issues in that case ?15:44
cedksharoonthomas: what do you want to cache?15:45
cedksharoonthomas: that's doesn't fit in a dict15:45
sharoonthomascedk: for our (nereid) own caching needs we have a generic cache backend… this is about the tryton cache which is troublesome especially when you run multiple workers/gunicorn instances15:46
cedksharoonthomas: what is the problem with Tryton cache?15:48
sharoonthomascedk: that is works per instance and when you write it may happen on one instance and the read from another15:49
sharoonthomascedk: so the data though consistent in DB, is inconsistent in memory across the server daemons15:49
cedksharoonthomas: not if you setup mutlti_server15:50
sharoonthomascedk: not sure why but it still seems to have issues with the translated fields15:52
cedksharoonthomas: just use something like: https://github.com/thadeusb/flask-cache to cache pages15:52
sharoonthomascedk: i am trying to debug15:52
cedksharoonthomas: translated fields are not cached15:52
cedksharoonthomas: there are very few stuff cached in Tryton because invalidation is too complex in most case and we add it only on critical place15:53
tarunbhardwajcedk: https://github.com/tryton/trytond/blob/2.6/trytond/ir/translation.py#L7215:58
cedktarunbhardwaj: ha yes16:00
cedkbut translation is quite static16:00
tarunbhardwajcedk: but after translation content get cached16:01
cedktarunbhardwaj: don't understand16:01
tarunbhardwajcedk: after translation translated content get cached in tryton instance, refer: https://github.com/tryton/trytond/blob/develop/trytond/ir/translation.py#L21616:03
cedktarunbhardwaj: and what?16:03
sharoonthomascedk: looks like this works even if multi_server is True ?16:05
tarunbhardwajcedk: lets consider there are multiple instances and then on update in translated content cache will only get clear for an instance only16:05
cedkI don't understand what you want ?16:06
tarunbhardwajother instance cache will still be invalid16:06
cedktarunbhardwaj: false16:06
sharoonthomascedk: the way the cache works is fine, but get and set methods of cache does not respect multi_server setting on tryton config16:07
cedksharoonthomas: proof ?16:07
sharoonthomascedk: the check for multi_server is done on the methods in the cache class16:08
sharoonthomascedk: like: https://github.com/tryton/trytond/blob/develop/trytond/cache.py#L7516:08
sharoonthomascedk: https://github.com/tryton/trytond/blob/develop/trytond/cache.py#L9716:08
sharoonthomascedk: https://github.com/tryton/trytond/blob/develop/trytond/cache.py#L10516:08
sharoonthomascedk: but for get and set you don't look at it (see: https://github.com/tryton/trytond/blob/develop/trytond/cache.py#L44)16:08
cedksharoonthomas: there is sense to look at it16:08
sharoonthomascedk: so from the reference of tarunbhardwaj it can be seen that you call get which will not check if the configuration currently says multi_server16:09
tarunbhardwajcedk: yes16:10
cedksharoonthomas: we don't care16:10
sharoonthomascedk: similarly, the set when called from translation (https://github.com/tryton/trytond/blob/develop/trytond/ir/translation.py#L434) will not respect multi_server16:10
cedksharoonthomas: we don't care16:10
cedkcache is local !!!16:11
sharoonthomascedk: why ? then the information on some servers would be wrong16:11
cedksharoonthomas: no16:12
sharoonthomascedk: rather "stale" would be right word as the data is outdated and only the server which made the update would have it in the cache16:12
cedksharoonthomas: with cache there are always delays16:12
cedksharoonthomas: no just put multi_server !!!16:12
sharoonthomascedk: agree with caching and delays, but when you use multi_server the cache should not be there ?16:13
cedksharoonthomas: cache should always be there16:14
cedksharoonthomas: with multi_server it is just invalidated between instances16:14
sharoonthomascedk: in this case when would the invalidation happen ?16:15
sharoonthomascedk: i think it would only happen when the restart does16:15
cedksharoonthomas: on new request16:15
sharoonthomascedk: well that does not happen16:15
cedksharoonthomas: it does: http://hg.tryton.org/trytond/file/5bd1e13ab72d/trytond/protocols/dispatcher.py#l13316:16
jvblascohave a nice weekend everyone ;)18:37
jvblascosee u on monday ^^18:37
-!- abhisar(~abhisar@42.110.56.172) has left #tryton18:49
-!- abhisar(~abhisar@42.110.56.172) has left #tryton19:03
-!- vcardon(~vcardon@LNeuilly-152-23-15-185.w193-252.abo.wanadoo.fr) has left #tryton19:50

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