can i access data in a report trigger ? *** SachaS has quit IRC *** holycow has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** johannesV has joined #gnuenterprise good morning hi johannesV good morning * holycow waves to all awake btw. introducing a unittest to appserver will give us a gnue-appserver/tests directory .... any complaints about ? ok no complaint :) ok *** sjc has joined #gnuenterprise *** kilo has joined #gnuenterprise *** btami has joined #gnuenterprise btami: u around? hi lekma, and yes hi do you know if it's possible to put today's (now()) date in a grd? one solution is gicing it as a parameter to report s/gicing/giving you can find examples using parameters in monthly.grd reinhard: using a datasource as FK for a field in a form, if i use the same datasource as FK for another field, should they 'move' together? yes see dtsCountry in sample.gfd hmmm, ok, thx, then it is an error on my side in appseever/samples, right? *** sjc has quit IRC well, that sample differs from what i want (as usual...) because there it is one field and two different descriptions you show but i need 2 fields both tied up to the same datasource as FK and 2 different descriptions so both of the fields can have a different keyvalue at the same point of time ... ? *** holycow has quit IRC *** kilo has quit IRC *** kilo has joined #gnuenterprise kilo: sorry, I don't understand what you want ah oh I think I get it you have 2 different fields that both reference the same table changing the value of the first (using a dropdown) does *not* change the value of the second field in terms of address sample you have somthing like a "country where the person lives" and a "country where the person was born" (since these are two different columns in the backend too) kilo: right? reinhard: nope it is like country code and country name, both same record in the foreign table so you basically store redundant information in your main table? you have both country code and country name in your main table? and country name should follow the selection of country code magically? yes, yes, yes ah that's easy to answer the answer is: i have no idea :) I would *think* that it could work actually hrmmm no lol i really have no idea would have to investigate how *does* it behave? bbl *** kilo has quit IRC *** kilo has joined #gnuenterprise *** btami has quit IRC kilo, i don't think that could work you have two dropdowns, one for the name and one for the number of days both dropdowns are connected to different fields in the main table no, 1 dropdown for name, the other one doesnt get displayed at all so if you change the name-field (by selecting a value from the dropdown) you change the db-column name, but in the other column (days) there is still a NULL value (or None) ah, you only have one dropdown ? yes, only one the days wont get displayed it is in the block though so it would get into the table so why don't you define a OnValidate trigger then, storing the proper days-value on commit ? it is exactly how it is now (not committed yet), but i was searching for a better alternate why is that alternative better ? it would mean you have to take care of that whenever you create such an invoice if you have an OnVAlidate-trigger you don't have to take care of it ... even if you create invoices using language-interface-apps or, to say it in other words, you put quite a lot of logic into that gfd then ... hmmm, dunno but this way an unneeded field should be there in the gcd file which 'unneeded' field ? that keeps the gnue_id of the paymentmethod until OnvValidate fills up the name and days fields hmm, that's right ... is the name unique ? logically yes, but people can be 'inventuous' yeah, right, it's not safe anyway ... it's a quite tricky problem ... :) *** dimas_ has joined #gnuenterprise lol like reinhard would say: hmmmm *** tiredbones has joined #gnuenterprise *** dimas has quit IRC *** kilo has quit IRC *** jamest_ has joined #gnuenterprise *** tiredbones has quit IRC *** johannesV_ has joined #gnuenterprise *** johannesV has quit IRC *** mnemoc_ has joined #gnuenterprise *** mnemoc has quit IRC *** GI has joined #gnuenterprise hallo reinhard hi GI (we talk English in this channel) :-) ok - we have a problem with mysql - you know this error - isn't it solved in version 4.1 which error? * reinhard has a memory that sucks sometimes it was the error with the create/modify date *** jcater has joined #gnuenterprise hmmm... if it is what I think it was then it was fixed 2005-01-31 (which was the very same day) 18:02:05 and should be included in 0.4.1 even in 0.4.0 that's what i expected :'( can you paste the error message here? even it is a very long one ??? the last few lines (~10 lines) should do it one moment resultSet= self._dataObject.createResultSet(conditions,readOnly,sql=sql) File "/usr/lib/gnue/python/gnue/common/datasources/drivers/Base/DataObject.py", line 90, in createResultSet readOnly=readOnly, masterRecordSet=masterRecordSet, sql=sql) File "/usr/lib/gnue/python/gnue/common/datasources/drivers/DBSIG2/DataObject.py", line 191, in _createResultSet cursor = self._connection.makecursor(query) File "/usr/lib/gnue/python/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 299, in makecursor cursor.execute (s) File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 137, in execute self.errorhandler(self, exc, value) File "/usr/lib/python2.3/site-packages/MySQLdb/connections.py", line 33, in defaulterrorhandler raise errorclass, errorvalue OpterationalError: (1109, "Unknown table 'gnue_module' in where clause") this happens when you start appserver? no, but when i start gnue-forms appserver://gnue/form/geminfo_gs you didn't want appserver://appserver/form/geminfo_gs ? you have to give the connection name of the appserver connection from connections.conf not the db connection btw we have added a lot of documentation on installation and configuration meanwhile you might want to look at /usr/share/doc/gnue* thank you for your advice, reinhard did it help? was it the URL? it was the url, but ... unfortunately i got another error i better stop working today and have a glas of beer lol or better a bottle you have this on your notebook? you could take it with you on our next meeting no, on the notebook, it works perfectly ah ok protocol error usually points to some mismatch of python version or xmlrpc version between client and server but I guess you run client and server on same machine, don't you? yes, i do python version is 2.3.5c1 cu next meeting and thx Reinhard ok please check that you use pw_xmlrpc for both server and client and don't use py_xmlrpc cu *** GI has left #gnuenterprise some day I will wake up in the middle of the night, full of sweat, eyes wide open, and shout "Protocol error! Protocol error!" :( we get this about once or twice a month and *never* find out what it was usually it ends with something like "well, I just reinstalled xyz and now it works" :( *** lekma has quit IRC *** SachaS has joined #gnuenterprise *** tiredbones has joined #gnuenterprise jamest_, jcater: 2 questions on GDataSource is getQueryString only for query by detail, or do you use it otherwise, too? (it seems to be not available in the trigger namespace anyway ) i believe is was only for query by detail and why does deleteCurrentRecordsetEntry use currentResultSet.getPostingRecordset() instead of currentRecordSet.current ? *** elwis has joined #gnuenterprise (or in other words, what's the secret behind that getPostingRecordset anyway?) i didn't think recordsets iterated through all the records during a post. is current actually kept up to date ? that was worded poorly on my part i didn't think recordsets moved current thru the records during the post no, they don't as i was thinking that'd trigger things like details recordsets to change as well that's what I thought the getPostingRecordset was used for but the delete function in GDataSource's trigger namespace isn't called during post to track the actual record that was being worked on hmm as for not using .current you thinking OnCommit triggers? that I don't know i was thinking triggers and detail records *** btami has joined #gnuenterprise what triggers do you use GDataSource.delete in? I believe getPostingRecordset is undefined (or, better put, None) in all triggers except ON-COMMIT well even in ON-COMMIT afaict *** elwis has left #gnuenterprise looks like reinhard realy enjoys working on gnue :) *** sjc has joined #gnuenterprise reinhard, are you there ? yes what should happen if one calls requery for a non-existing key ? who is "one"? me :) lol I mean where is requery used? ERROR: testConnection (__main__.ConnectionTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "data.py", line 407, in testConnection u'1000000000000000000000200000000F', [u'address_name', u'address_code']) File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/appserver/data.py", line 902, in findRecord new = self.__backend ().requery (table, {u'gnue_id': row}, uncachedFields) File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/common/datasources/drivers/Base/Connection.py", line 219, in requery return gLeave (8, self._requery (table, oldfields, fields)) File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 462, in _requery list = self.sql (statement, parameters) [0] IndexError: list index out of range ok, it's a bit hackery ... but the connection instance (data.py) has a method "findRecord (table, row, fields) so i could call that method using a (table, row) pair which has no counterpart in the backend, and well ... it produces the IndexError hmmm that could even happen with a load I think as load would call findRecord with what it got as gnue_id IIRC exactly so actually the requery function in DBSIG2 should generate a better exception to start with yes, i think so at least it should returns something like 'None' instead of raising an indexerror and IIRC we have defined a "no such instance" exception anyway in appserver yes, but that's raised too late see geasSession.py, line 483 cause the findRecord fails before as i see things, requery () should either give a defined result or raise an exception yep at first thought I would prefer an exception because for most other cases where it is called the absence of the backend record shows that there's something rotten there are two places using a backend.requery () in data.py atm, connection.findRecord () and record.getField () most other cases == in datasources/dbdrivers/Base if requery raises an error, we could catch it and reraise it as InstanceNotFoundError in geasSession.py right and let it through in all other cases (like getField () where it must not happen anyway) exactly it's quite amazing to write testcases; the major thoughts are: how can i infiltrate a defined api :) ok, it's time for me to quit now ... have a nice evening :) you too yeah, thanks :)) *** johannesV_ has quit IRC *** tiredbones has quit IRC *** kilo has joined #gnuenterprise *** sjc has quit IRC *** chillywilly has quit IRC *** btami has quit IRC *** jamest_ has left #gnuenterprise *** chillywilly has joined #gnuenterprise ******************************** NOTICE I have removed the SELECT WHERE 1=2 query for creating an empty result set and AFAICT everything still seems to work fine you did NOT try SELECT WHERE 1=3, did you? 8-)) kilo: roflmao if you have *any* problems related to that please let me know I will now commit following the old gnue principle change it and see who screams ;-) hmm so how do you know data types now? AFAICT data types did not get extracted from the cursor description or did I overlook someting? ah I thought they did maybe not it's been a while but that was the idea between 1=2 not just so we could hit the database for the fun of it :) maybe they have been in former versions but maybe that's from years past but that would explain a lot because I have tried to find out what's the background behind that query for years without success :) because other tools besides forms, or using in custom code there's no to tell us data types * jcater wonders how that works now also, iirc, it was possible to have a datasource without bound fields and get all fields in that table that might've been broken though the "select *" stuff? that should still be working yeah except that an empty recordset wouldn't know about its fields which I am not sure if that would be useful at all because such datasources usually would not be writeable, would they? yes, but I'm not sure how much of that code is out in the wild i.e., in a custom gnue-common app I could create a datasource do .createRecord() set the values and commit it without having to manually bind fields jamest will be a good person to ask if he has code doing it that way or did he always bind fields actually jamest said a few days ago that he wouldn't mind if we broke SELECT * completely as he didn't like it but I wonder if he realized that meant simple inserts too? well, even in this one case I'd say commit your code and see how it goes worst case we just have a test before doing an insert to see if we have bound fields if not, then at that point, do a select ... where 1=2; but if no one yells, then I guess it wasn't used :) I've already thought about asking introspection for a list of fields if no fields are explicitly bound instead of just doing a select * that works as long as we have introspection would have the advantage to also work for non-sql backends we have a lot more drivers without sql support than drivers without introspection actually we have zero drivers without introspection currently even dbffile, inifile, csvfile, and appserver support full introspection odbc? not there any more really? was deleted for years of not-being-maintained hasn't even been updated to the dbdrivers reorganization *you* did a long time ago with separation of Connection object etc that sucks I understand though did you see my question yesterday? how would you create a DataObject without DataSource? doubtful I got a promotion in February which sucks my understanding was always that you would use a DataSourceWrapper in such a case * jcater doesn't get to follow in irc as much I don't think that was a requirement designer used dataobjects directly ah but that's been replaced with Connections ah ok so I'm ok with making it a requirement allright but historically it hasn't been because AFAICT at several places stuff is there like self._dataObject._dataSource._onRecordLoaded(self._cachedRecords[-1]) unconditionally actually and I wondered if I would have to fix that with Python 2.3's new delayed-initializing "new" classes we could combine datasource and dataobject if we wanted too I think jcater: good you say that I hated the distinction but the reason we had a distiction is that the datasource() init code couldn't know the type='...' yet or connection='...' but I think the new-style classes would allow that It might well be that the current reorganisation ends up with the code to create and execute a query moving from DataObject to ResultSet (IMHO it would be more logical to have it there) the backend dependent code that is which would probably make the DataObject DataSource merge even easier *wow* it seems the ongoing dbdriver reorg reduced lines of code by about 50% with same (or even improved) functions just by removing duplicate code, unused code, making better base classes for drivers etc and I guess that docstrings count as lines of code, and I've added quite some gack! 1:20 a.m must go to bed night all (will read the logs) *** reinhard has quit IRC *** jcater has quit IRC *** kilo has quit IRC *** jcater has joined #gnuenterprise *** jcater has quit IRC *** jcater has joined #gnuenterprise *** dimas has quit IRC *** jcater has quit IRC *** holycow has joined #gnuenterprise *** holycow has quit IRC *** dimas has joined #gnuenterprise