good morning good morning *** sjc has joined #gnuenterprise *** dcmwai has quit IRC *** holycow has quit IRC *** reinhard has joined #gnuenterprise hi *** btami has joined #gnuenterprise hi hi all readgcd fails here: DB000: File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/ResultSet.py", line 102, in _query_object DB000: self.__count = connection.sql1 (query, params) DB000: File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 313, in sql1 DB000: cursor = self.makecursor (statement, parameters) DB000: File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 259, in makecursor DB000: cursor = self._native.cursor () DB000: AttributeError: 'NoneType' object has no attribute 'cursor' L reinhard: just wanted to test filters with gnue-invoice, and run setup-db.sh if filters ok with empty db for you ? btami: I think this is a different problem you have here ls err *** aries_mindworks has joined #gnuenterprise hi btami: already tracking this error where can I find gnue-contrib from svn? reinhard: yes, the last question is another pb hi aries_mindworks i don't find it anywhere btami svn co svn://svn.gnuenterprise.org/var/svn/gnue/trunk gnue-contrib gets the gnue not gnue-contrib no trunk needed for gnue-contrib so svn co svn://svn.gnuenterprise.org/var/svn/gnue gnue-contrib i see svn co svn://svn.gnuenterprise.org/var/svn/gnue-contrib you should put this hint into the svn instructions btami: readgcd should be fixed now on http://www.gnuenterprise.org/developers/svn.php thanks for your help bye *** aries_mindworks has left #gnuenterprise btami: we have visitors this afternoon, I will look at filters later ok, thx grrr even more stuff broken :( empty filter class works for me bbl *** reinhard has quit IRC *** havoc has quit IRC *** havoc has joined #gnuenterprise *** barsema has quit IRC *** SachaS has joined #gnuenterprise regards from New Orleans ;) reinhard: empty filter class is OK it was my fault tried it with gfcvs grid.gfd depending on filter sorry bye *** btami has quit IRC *** holycow has joined #gnuenterprise *** rynik has quit IRC *** SachaS has quit IRC *** SachaS has joined #gnuenterprise *** jcater_ has joined #gnuenterprise *** kilo_ has joined #gnuenterprise *** mnemoc has quit IRC *** jcater_ has quit IRC *** mnemoc has joined #gnuenterprise *** jcater_ has joined #gnuenterprise *** reinhard has joined #gnuenterprise reinhard: you have a second? yes I'm trying to debug a problem I'm having with datasources actually I joined irc just because i saw your commit mails I use the PyPGSql driver so it may be specific to that but if I open a form fresh add a record then commit it the record is committed but the __do_requery fails ok I can test btw did you have problems with the wrong exception? well actually the __initplugin__ should already raise the right exception when I svn updated the PyPG driver was trying to use "PgSQL" and the import in the Connection code should never fail at all yes, I got a huge traceback w/ImportError on PgSQL oh yes I see I planned to ask when someone got in if I was patching the wrong section of code that's because the module imported in __init__ differs from _driver_name it's ok it should never happen, but it happened due to a bug in the driver :) it would *not* happen if the driver was written correctly but pypgsql was simply not installed but in any case it's an improvement jcater_: you get an AttributeError: keys ? yes ok appearantly I can reproduce :) cool incidentally those strange Oracle issues I was having for so long, but I couldn't trace the source of the behavior they don't happen any more so I can use gnue-forms with oracle once again :) DB003: 0:00:43.278 [Connection:258] DBSIG2 Statement: SELECT State FROM State WHERE oid IS NULL bingo pypgsql doesn't support rowid's :( bleh well, I will switch to psycopg but that sucks hold i it appearantly pypgsql is the postgres driver that sucks most oddly enough, I switched to pypgsql a few years ago it has _broken_fetchmany (i.e. it raises an exception when no more records are left instead of just returning none like *all* other drivers) because psycopg gave me so many issues but it looks like they've switched roles :) and it seems to not support lastrowid at all sigh just a second yep, confirmed it also has a broken rowcount yep fixed all of them but it seems forms really does strange things when the ResultSet returns a recordCount of -1... jcater_: can you please svn up and try again? still get an attribute error (keys) you've defined a primarykey in your form? yes ok removing the pk causes it to work is the pk generated? hmm, no do you see something strange when you turn on debug-level=3 (sql output)? SELECT city, agency_code, name, zip, address1, address2, address3, fed_id_type, state, contact_email, fed_id, inactive_date, contact_name, contact_phone,id FROM agencies WHERE id IS NULL I'm sure it's because the pk wasn't being filled pre-commit yes this is the reason quite sure when is the pk being filled? is not a not-really-the-pk-but-i-pretend-so kind of pk? it is a real pk or is it filled on db trigger? that postrges fills with a default ok normally I add a trigger to do it as well which I will do on this form too now as pypgsql has no oid support there is no way for gnue to get the value of id at all but we should still probably have some logic here that postgres assigned it would mean we would not be able to update that record later if the connection.requery returns nothing, can we abort the __do_requery as if no PKs were defined? so at least it doesn't bomb with an error? or does that break something else? (in RecordSet.__do_requery) I think it would break the next attempt to update the same record the __wherefields would not only have to check if there is a __primarykeyFields defined, but also if they are not None and also IMHO the better option would be to not call __do_requery at all in requery() if self.__rowidField or self.__primarykeyFields: self.__do_requery (self.__boundFields) this would have to be replaced by something like fwiw I had a primarykeyseq="..." defined on that datasource so apparently that doesn't work if self.__rowidField or self.__primarykeyFieldsFilled() oh I just noticed that I think I see the problem..... yes if len (self.__primarykeyFields) == 1 and \ self.getField (self.__primarykeyFields [0]) is None and \ self.__primarykeySeq is not None and \ hasattr (self.__connection, 'getsequence'): it's getSequence, not getsequence :) arrgghhh!! can you fix it? yes, I am does it work with that fix? hmm no return self.sql1 ("select nextval('%s')" % name) File "/home/jason/checkouts/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 316, in sql1 cursor = self.makecursor (statement, parameters) File "/home/jason/checkouts/gnue/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 267, in makecursor cursor.execute (s) File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 3091, in execute self.res = self.conn.conn.query('FETCH 1 FROM "%s"' % self.name) OperationalError: ERROR: relation "agency_seq" does not exist but I wonder where that 'FETCH 1 FROM "%s" comes from err, typo on my part yes, that fixes it excellent honestly I'm still amazed that I didn't break more :) me too :) I was in shock oracle even worked at all :) * jcater_ ducks lol no kidding I had no chance to test oracle at all, so I did everything more or less blindfoldedly the funny thing is I'm really approaching the 50% mark ? sloccount of datasource comparing last release to current svn s/datasource/datasources/ ah *** SachaS has quit IRC current svn is 5745, last release was 10439 55% but the most important thing for me is: for the first time in my life, I feel like I basically understand what is happening all around in common :) good, I'm glad jcater_: as you're here, do you remember this:? # Used in GRSources.__connectMasterDetail to link detail datasource to # master source. Called by the ResultSet when master changed # This will actually be over-written by GRDataMapper but at the time # the master-detail must be linked, the GRDataMapper will not have been # created yet. [Yes, it's fugly] def masterResultSetChanged(self, masterResultSet, detailResultSet): # [This is overwritten by GRDataMapper._masterChanged] pass LOL would you be able to remove this if datasources supported events? not really ah ok I think so reports is one of the reasons I wanted those events to get rid of crap like that so, I'd say yes it's the only place where masterResultSetChanged is used at all (at least the only place left now) and introducing events I would like to see those old methods go away but anyway I should be heading for the bedroom, gotta work again tomorrow jcater_: if you have more problems with datasources I will be happy to help tomorrow good night all (of course the same holds for everybody else, too) :) *** reinhard has quit IRC *** lekma has joined #gnuenterprise *** jcater_ has quit IRC *** sjc has quit IRC *** dcmwai has joined #gnuenterprise *** Vee has quit IRC *** jcater has quit IRC