IRC logs of #tryton for Saturday, 2011-04-02

chat.freenode.net #tryton log beginning Sat Apr 2 00:00:01 CEST 2011
-!- woakas(~woakas@200.106.202.91) has joined #tryton00:47
-!- yangoon(~mathiasb@p54B4E252.dip.t-dialin.net) has joined #tryton05:18
-!- alimon(~alimon@189.154.109.4) has joined #tryton06:33
Mayankcedk: ping!06:37
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton07:21
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton08:27
-!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton09:43
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton10:12
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton10:30
-!- FWiesing(~franz@mail.tryton.at) has joined #tryton10:46
-!- Mayank1(~beakkon@122.173.195.64) has joined #tryton11:23
-!- enlightx(~enlightx@dynamic-adsl-94-34-174-1.clienti.tiscali.it) has joined #tryton12:42
-!- Mayank(~beakkon@122.173.198.132) has joined #tryton13:24
Mayankcedk: Hello, I was unable to catchup on the project. Had a very busy week. Cazou yesterday opted for the Gantt Chart idea yesterday. The idea of adding historical timeline to the GTK client. The same has been on the Ideas list of 2009 and 2010 too. This would be really helpful in conditions where recoveries are required or when a general revert to older record versions are required. Can I know something about the implementation?13:56
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has joined #tryton13:57
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton13:59
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton14:02
cedkMayank: there is no doc on the implementation14:12
cedkMayank: you can search in trytond for _history which is the attribute that activate the history14:12
Mayankcedk: any rough idea would help?14:13
Mayankcedk: ok thanks!14:13
Mayankwill look into it14:13
cedkMayank: the design is quite simple, for Models with _history = True a table __history is created14:14
cedkMayank: and for each modification of row in the main table a copy is done in __history one14:14
cedkMayank: also there is no issue to have students that apply on the same idea14:15
cedkMayank: the best one will be choosen14:15
cedkMayank: that's why we encourage to apply for more than one idea14:16
cedkMayank: you can have a look at http://hg.tryton.org/modules/sale_opportunity it is a module that use _history functionality14:17
Mayankcedk: I will look up the __history table and play with records. I initially planned to send in two proposals one for creating a module that generates SQL string (sticking to the initial one) and this one. As I am already  behind the planned schedule I want to prioritize work on the main proposal first and then get back to the initial one (for which the other students are already applying). Though I am behind the time-line, I really want to be a successful 14:25
MayankI will install the sale_opportunity module and get into the code.14:25
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton14:57
-!- nicoe(~nicoe@193.200.42.59) has joined #tryton15:21
-!- nicoe(~nicoe@193.200.42.59) has left #tryton15:28
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton15:32
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton15:36
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton15:51
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has joined #tryton16:03
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:07
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:17
-!- Mayank(~beakkon@122.161.39.86) has joined #tryton16:20
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:22
sharoonMayank: did u check the sale_opportunity module ?16:41
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:42
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:47
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:52
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton16:58
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:03
-!- caravel(~caravel@1.Red-81-44-157.dynamicIP.rima-tde.net) has joined #tryton17:04
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:08
-!- alimon(~alimon@189.154.109.4) has joined #tryton17:11
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:15
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:20
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:25
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:30
-!- chrue(~chrue@host-091-097-069-118.ewe-ip-backbone.de) has joined #tryton17:31
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton17:32
-!- ikks(~ikks@190.158.104.249) has joined #tryton17:33
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:35
-!- svaksha(~svaksha@unaffiliated/svaksha) has joined #tryton17:40
-!- Mayank1(~beakkon@122.162.144.196) has joined #tryton17:55
-!- Mayank1(~beakkon@122.162.144.196) has left #tryton17:55
-!- sharoon(~sharoon@173-9-190-190-miami.txt.hfc.comcastbusiness.net) has left #tryton18:12
-!- alimon(~alimon@189.154.109.4) has joined #tryton19:19
-!- Mayank(~beakkon@122.162.144.196) has joined #tryton20:38
-!- Mayank1(~beakkon@122.161.36.182) has joined #tryton20:51
-!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton20:54
-!- sharoon(~sharoon@173-9-190-190-miami.txt.hfc.comcastbusiness.net) has joined #tryton20:59
-!- sharoon(~sharoon@173-9-190-190-miami.txt.hfc.comcastbusiness.net) has left #tryton21:02
-!- sharoon(~sharoon@173-9-190-190-miami.txt.hfc.comcastbusiness.net) has joined #tryton21:03
-!- okko(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton21:21
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has left #tryton21:52
Mayanksharoon: yes i checked the sale_opportunity module looked up the __history table. Also other modules - account_invoice_history, product_cost_history, the tables - _line__history have __id field. So the project will be to create a display which can show the old records in accordance with a timeline. Can reverting back to these old records be also implemented? If yes, then the present needs to be stored too I guess.21:56
cedkMayank: reverting back will be just writing old value to the record22:06
Mayankcedk: yes, so it can be implemented as well. To deal with the current records can we store them as well? And add to the timeline with a tag like - current records or future/post-date records (when an administrator chooses to revert to the old ones)?22:10
cedkMayank: no, the current record must be only stored in the origin table22:21
Mayankcedk: Ok, but how will it deal with a condition where there it is desired to revert back to the old records, and keep the current records (those added after the date of revert) as well.  I may be getting it wrong.22:25
cedkMayank: I don't understand, revert back will always modify the current record22:32
Mayankcedk: What I am trying to say is, let the  current date is - 2nd April, 2011. A person wants to revert back to the records that were there on 21st March, 2011. But he has added new records between 21st March and 2nd April 2011. The person wants to revert back to the records of 21st March, 2011, but at the same time does not want to lose the new records that he/she added after 21st March. So how to deal with it? Can there be a tag on the timeline which shows22:38
sharoonMayank: just writing new values (from the __history record) into the master table will create a history record for the current record22:40
sharooncedk: Mayank: http://images.apple.com/macosx/what-is-macosx/images/timemachine_hero20090608.png22:43
Mayanksharoon: yes thats exactly what I meant. I havent used the Timemachine though, but it must have the feature of saving the current records I assume. Is it already implemented in tryton this way? If yes, then in the historical time-line  can we have a region that shows up your "future" records that were there before the revert?22:47
-!- fares(~fares@41.225.109.190) has joined #tryton22:57
sharoonMayank: Let me reuse your example.23:00
sharoon2nd April23:00
sharoonMaster Table:23:00
sharoonname => apple23:00
sharoonHistory Table:23:00
sharoon21st March: name => pear23:00
sharoon22nd March: name => orange23:00
sharoon30th March: name => grape23:00
sharoonif on 2nd april you write to the record that the name is pear, then it is equivalent to reverting to 21st mar23:01
sharoonin the write event, tryton will automatically insert the record with apple into the history table23:01
sharoonso your history will now look like:23:02
Mayanksharoon: oh, yes. I get it. Thanks!23:02
sharoon21st March: name => pear23:03
sharoon22nd March: name=> orange23:03
sharoon30th March: name=>grape23:03
sharoon2nd April=>apple23:03
sharooni think i have missed the behaviour slightly, cedk could confirm - i think the history records are created for the latest record also23:03
sharoonMayank: http://hg2.tryton.org/trytond/file/63841a1a6bd6/trytond/model/modelsql.py#l39723:06
sharoonMayank: a history record is created whenever a create happens, so in my example the history table will have one more record (the current entry in master table as well)23:07
cedksharoon: yes the last entry of history table is the current record23:08
sharooncedk: yep, http://hg2.tryton.org/trytond/file/63841a1a6bd6/trytond/model/modelsql.py#l90223:08
sharooncedk: have you used blinker ? http://pypi.python.org/pypi/blinker/1.023:09
cedksharoon: no23:09
sharooncedk: i used it for an openerp module to emulate the functionality of triggers in tryton.23:10
Mayanksharoon: thanks for the link, Ok, so the apple record will go in the __history table as well. So now for creating a timeline display the display should be able to distinguish between todays record and other history  records.23:10
MayankI mean a section/region showing - "Today" or as  a whole combined in "History"23:11
sharoonMayank: I have not thought about the design itself, but probably what could be done is have a progress bar/which works like a timeline bar in the history view and on_change of the progress bar value, reload the record with that datetime as  _datetime in the context, that should send you the record as it was on that day. see http://hg2.tryton.org/trytond/file/63841a1a6bd6/trytond/model/modelsql.py#l47623:13
sharoonMayank: I think that is what the design expects, you can confirm with cedk or put up your own proposal :)23:13
cedksharoon Mayank agree23:15
Mayanksharoon: Hmm, thats what the design should be like. cedk has already confirmed it. I will go through modelsql.py and start working on my proposal too.23:18
Mayankcedk, sharoon: Thanks for your time :)23:18
Mayankproposal/application*23:19
sharoonMayank: good luck, I am sure it will be a wonderful idea to implement.23:19
Mayanksharoon: Yep, definitely it will be. Thanks again.23:21
sharooncedk: do you think we could use blinker for signalling/trigger in tryton23:37
cedksharoon: don't know23:41
cedksharoon: but I think you could make trigger sending message to a server that will broadcast it23:42
sharooncedk: that will be a message queue ?23:43
sharooncedk: BTW, i was running celery with tryton to do a bulk data transfer + integration with some legacy systems for a customer and his e-commerce systems... i ran into some assertion errors with Transaction after some time23:44
sharooncedk: have you seen such issues before ?23:44
cedksharoon: no23:47
cedksharoon: you should post traceback23:47
sharoonok, i am really not sure its related to something to do with celery configuration, i am rewriting script now. the moment i see the issue again i willpost a traceback23:48
sharoonthe work made me think about the tryton request dispatching itself, which could infact be replaced with a message queue and workers23:49
sharooncedk like the netrpc and xml rpc requests delegating asynchronously to something like rabbitmq and then worker threads starting from dispatching to model/method23:51
sharooncedk: do you think that will improve the scalability ?23:51
-!- alimon(~alimon@cablelink219-34.telefonia.intercable.net) has joined #tryton23:51
cedksharoon: don't think async will improve perf23:54
alimonhi23:54
sharooncedk: ok23:54
cedksharoon: but if workers are separate process than it will23:54
sharooncedk: workers could be even on differetn machines23:54
sharoons/differetn/different23:54
sharooncedk: and ofcourse workers could be different processes and are concurrent themselves23:55
cedksharoon: not sure it will help to have on separate machine because you will still have the database as bottleneck23:56
sharooncedk: agree23:56
sharooncedk: also something i liked is celery beats - which could replace the scheduler/cron we have23:57
-!- caravel(~caravel@1.Red-81-44-157.dynamicIP.rima-tde.net) has joined #tryton23:57

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