dimas: you here? yep *** yure_ has joined #gnuenterprise *** sjc has joined #gnuenterprise *** afromm has joined #gnuenterprise Hi to everybody. After being away for some days I come back to work on my app, abd of course am getting some trouble again. I do want to display several entries releated to a master field, which are linked by a linking table. I first set up the datasource for the linking table, defined a block for it, but and the same for the referenced table. For defined the entry-fields of the referenced... Then I defined a view (I'm using Postgres) as a join betwenn the linking and the referenced table and would like to display the data from that. When running the form I get a huge error window, so large that it doesn't fit on my screen and as it is not scrollable, I can't read all the error messages. This is probably something that should be fixed. Turning debuging on, I could find out, that... ...table and set it to display 5 rows, but of only one referenced item showd up. I guess that only one item from the linking table is fetched but don't know why. ...when fetching data from the view, the oid column is requested which is not present in the view and raises an error. Why is the oid column included in the select query for a table? hi afromm are you using gnue-appserver as well? No, just plain gnue-forms conecting directly to postgres probably i had something like this once but it was too long ago.. may be jamest could help you with this one Including an oid coulm to the view solves the problem, but I consider this a more or less dirty hack. Why is the query issued with the explicit column list instead of just a *, specially as the explicit-field parameter seems not to be implemented? *** johannesV has joined #gnuenterprise *** menomc has joined #gnuenterprise *** mnemoc has quit IRC *** sjc has quit IRC *** sjc has joined #gnuenterprise *** jamest has joined #gnuenterprise johannesV: did you get my email about assert gDebug? *** ajmitch_ has joined #gnuenterprise jamest, you mean that one sent to gnue-dev ? yeah yes I've already answered it ... just now? or a while ago as i haven't got any replies no, about two or three hours ago reinhard has replied to it too we both like your idea how is that -O option meant to be used ? do we do something like gnue-forms -O .... form.gfd *** ajmitch has quit IRC the -O is a argument to python hmm like in gfcvs just put a -O on the python call i think that setup.py build will create modules with -O enabled if wanted (i don't recall how) does that mean we can't select a --debug-* then ? ah, ok ... that would work absolute worse case IMO would be a wrapper like in bash for unix that looks to see if one of the args passed in is --debug-level and if so then it doesn't call python with -O what about having 'gfcvs' decide wether to add a -O or not (like if there's no --debug*) right :) but for gnue-forms that's an issue as that's pure python but in any case I think this is very doable just needs a little thought yes, exactly i figured the big hurdle would be you guys would disliking my bastardization of python's use of assert :) I've once thought about such a mechanism when i was optimizing appserver, but i haven't found a nice one no, i think this solution has something interesting ... :) it looks quite cool :) good i didn't dig too much but this may cleanup our debug code as when I was in there changing to return true it looked like debug reset it's gDebug call based upon something looked almost like the set it to a function containing only pass under some cases i didn't read too close as I just wanted to test the idea locally prior to the mail well, i thought if debug-level is not set, gDebug is set to a NOOP function right, only containing the command pass iirc yeah that was to cut down the performance hit on those calls iirc but the functoin call overhead still existed yes, i was about to say the same ... at least this was the result of my investigations using the profiler the same applies to checktype () if used in heavy used functions this consumes a remarkable part of the time, but it's a bit another deal with that one brb *** sjc_ has joined #gnuenterprise *** sjc has quit IRC *** sjc_ has quit IRC *** sjc_ has joined #gnuenterprise The other thing that makes the form allmost unusable is, that it takes increasingly longer to page from one record to the next. After pageing abaout 40 times, it takes several seconds ( > 3) to change the view to the next record. I tried to set the cachesize for all the datasources to a large value, but that didn't help much. Running the profiler I get that most of the time is spoent in... Hi, its me again with some problems. I finaly got form with all the features I need, but I'm getting a strange behavior. basicaly I have the following structure: block Master: controls three detail-blocks: A,B,C block A,B: are master blocks for blocks D,E,F,G ( A controls D and E, and B controls F and G ) When I page through the records, via a button conected to the Masterblock , everything shows up all right while paging forward, but when going back to previous records, just the data of 1st level detail blocks A,B,C is refreshed, but the 2nd level detail blocks D-G show the data of the last record of the visited list. Any suggestions on what is going wrong here? ...EventController.py:77(dispatchEvent). Is there a chance to optimize my form? Regards *** sjc__ has joined #gnuenterprise *** sjc_ has quit IRC afromm: is this the actual output? EventController.py:77(dispatchEvent). Is there a chance to optimize my form? The part After the dot is my question. The output ends after the brace. also I get that most of the time is spoent in... [12:08:33 pm] Hi, its me again with some problems. i didn't see where it's spending it's time the 3rd level detail block not refreshing on previous record has to be a bug Here is the compleate line of the profiler output: 174605 function calls (130823 primitive calls) in 10.210 CPU seconds Ordered by: internal time List reduced from 1466 to 50 due to restriction <50> ncalls tottime percall cumtime percall filename:lineno(function) 6384/101 1.010 0.000 6.010 0.060 /usr/local/gnue/lib/python/gnue/common/events/EventController.py:77(dispatchEvent) 16102/4769 0.490 0.000 1.130 0.000 /usr/local/gnue/lib/python/gnue/common/datasources/drivers/Base/RecordSet.py:468(__hasPendingChildren) 16076/4795 0.490 0.000 1.340 0.000 /usr/local/gnue/lib/python/gnue/common/datasources/drivers/Base/RecordSet.py:454(isPending) 13693/3518 0.470 0.000 1.450 0.000 /usr/local/gnue/lib/python/gnue/common/datasources/drivers/Base/ResultSet.py:604(isPending) 1 0.440 0.440 6.030 6.030 /usr/lib/python2.3/site-packages/wxPython/wx.py:88(MainLoop) 469 0.310 0.001 3.860 0.008 /usr/local/gnue/lib/python/gnue/forms/GFForm.py:956(refreshUIEvents) 1 0.240 0.240 0.240 0.240 /usr/lib/python2.3/site-packages/wxPython/__init__.py:14(?) 3384 0.200 0.000 1.670 0.000 /usr/local/gnue/lib/python/gnue/forms/GFObjects/GFBlock.py:348(isPending) 453 0.170 0.000 0.680 0.002 /usr/local/gnue/lib/python/gnue/forms/uidrivers/wx/widgets/_base.py:161(setValue) 8690 0.160 0.000 0.160 0.000 /usr/local/gnue/lib/python/gnue/common/logic/NamespaceCore.py:196(__setattr__) 460/5 0.160 0.000 0.670 0.134 /usr/local/gnue/lib/python/gnue/common/logic/NamespaceCore.py:75(constructTriggerObject) 4462 0.150 0.000 0.150 0.000 /usr/lib/python2.3/site-packages/wxPython/windows.py:1096(Enable) 1271 0.140 0.000 0.160 0.000 /usr/lib/python2.3/ConfigParser.py:489(get) 1187 0.140 0.000 0.220 0.000 /usr/local/gnue/lib/python/gnue/common/definitions/GParserHelpers.py:38(__init__) The rest are peanuts. It's the outpu of a run where I just page a few times (While profiling it takes really long to page to a new record) wow, that's some serious calls into the record set and yes, profiling is hard on performance Abaut the refreshing problem: What kind of bug could that be? I just define the "detaillink", "master" and "masterlink" attributes of the datasource. nothing on your end tell me, if you move forward 5 records everything updates fine right then if you move backward 3 records the 1st level details update but the 2nd level do not right what happens if you then move forward 1 record do the 2nd level details re-sync with the right info? *** johannesV has quit IRC *** johannesV has joined #gnuenterprise As long as I move to records I haven't visited, say tuntil the 5th record, I get the correct data displayed on the second level. When I go back any number of records, say 3, the data of the 2nd level is stays on record 5. When I go futher, to the 6th, 7th.. record, the data refreshes all right, when I go back, the data stays on record 7. but if you move forward 5 then back 3 then forward 1 what does the 2nd level stay on? (now that you're on record 4) The data stays on record 5 until I move to record 6 ok *** jamest has left #gnuenterprise *** jamest has joined #gnuenterprise BTW. setting the cache to 1 for the datasources doesn't help. i really think you've hit a bug in our datasources *** sjc has quit IRC i'll try and take a look after a bit but right now I'm working on some non gnue code that is giving me fits if i recall correctly you're a business owner/manager not a coder right? *** sjc has joined #gnuenterprise *** johannesV has quit IRC Me bigger concern anyway is th eperformance problem. I think the refreeshing thing will be fixable, but if I can't get a decent performance I'm afraid I will have to drop gnue. What is th experience of gnue with complex forms? Of course both problem could be related, becaus if something is not syncronising well, it probably is causing a performance issue also. Is there a way I can take a... ...closer look at this? I'm new to python, but quite used to profile code. i have several forms with 10 to 12 datasources but i don't think those do 3 level master/detail as far as performance i also don't have too many issues running w/ 10,000 to 20,000 records in memory with my maintenance forms (3 to 4 datasources) one thing that could hammer on performance is our caching isn't very intelligent if you have 40000 records in memory and jump to the last one then all 40000 will be loaded along with all their details at least that's how it initially worked but i doubt that changed during the recent updates that reinhard and co did however based upon what you're describing I could see that being an issue at least with regard to memory how many records are you loading? as to where to look in forms i dont' know off the top of my head :( I'm not loading to many records, my complete database has only abaut 180 records per table and 7 relevant tables. If the caching is causing the problem, then reducing the cache size to one record on each datasource should solve the problem, shouldn't it? I don't think its a memory problem, at least the memory footprint doesn't change while running the form. *** sjc has quit IRC that should be no problem for forms eh, wht exactly do you mean with 'that', The size of my database? my invoicing form uses 12 datasources and routinely loads 50 to 75 records in the master so it has to be some type of bug in datasources when dealing w/ master -> detail/master -> detail yes, the size of your database As I previously set up a form whith a M->D/M->D structure that worked all right, could it be a problem that some of the datasources refer to the same database table? I had to set up diferent datasources for most of the tables because each of them are controled by other master records. What shall I do now? Shall I post the structure of my form anywhere? if possible you could email to me at jamest@gnuenterprise.org but i won't have time to look for a bit * jamest is having major brain issues this afternoon need to code, want to sleep :) *** SachaS has joined #gnuenterprise *** madrian has joined #gnuenterprise Hello everyone. gnue's subversion server seems to be down. Does someone happen to know what's going on ? apparently noone is around. bye ... *** madrian has left #gnuenterprise *** afromm has left #gnuenterprise madrian: fixing i believe it's working again *** kilo has joined #gnuenterprise *** yure has quit IRC *** kilo has quit IRC *** nickr has quit IRC *** Amorphous has quit IRC *** Amorphous has joined #gnuenterprise *** nickr has joined #gnuenterprise *** jamest has quit IRC *** jcater has quit IRC