*** SachaS has quit IRC
*** mnemoc has quit IRC
*** SachaS has joined #gnuenterprise
*** mnemoc has joined #gnuenterprise
*** lxf has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** lxf has quit IRC
*** btami has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** SachaS has quit IRC
*** dcmwai_ has quit IRC
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
*** ayers has joined #gnuenterprise
*** psu has joined #gnuenterprise
*** holycow has quit IRC
*** btami has quit IRC
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** kilo has quit IRC
*** lupo__ has joined #gnuenterprise
<lupo__> huhu
*** jamest has joined #gnuenterprise
<reinhard> hey lupo__!!!
<reinhard> long time no see
<reinhard> will you be at LinuxTag?
<lupo__> hi reinhard
<lupo__> (will be back in 10 minutes, im in the library and doing some university stuff; but have to make a short break because i
<lupo__> am about to go crazy)
<jamest> can anyone confirm this error in forms
<jamest> open a master/detail record and move down a few records in the master (the detail will update)
<jamest> then move back up and the detail will not change with the master
*** titopbs has joined #gnuenterprise
*** Alexliu has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** Alexliu has left #gnuenterprise
*** psu has quit IRC
<reinhard> jamest: looking at it now
<jamest> reinhard: already commited a fix
<reinhard> jamest: this fix will break moving back to masters with uncommitted detail records
<jamest> sigh
<reinhard> it just disables caching result sets
<jamest> sorry
<jamest> i thought that return would prevent the reset of the details from being notified
<reinhard> sorry I was not looking when you wrote your request for confirmation
<reinhard> no, the notification would actually happen in _activateResultSet
<reinhard> just 2 lines before the return
<reinhard> interestingly I cannot even reproduce your effect
<lupo__> i am back
<lupo__> i will not be at linuxtag
<lupo__> quite a lot to do right now
<reinhard> jamest: I really wonder how removing that return could fix it at all
<reinhard> lupo__: you will miss something
<reinhard> :)
<lupo__> what will i miss? :-)
<reinhard> there are about 20 FSFE people there this year :)
<reinhard> well, at least way more than 10
<lupo__> i know
<reinhard> also, there will be people from FSFLA and Japan
<lupo__> cool
<reinhard> and it will be really cool :-)
<lupo__> well
<lupo__> i currently have to deal with neurobiology and biochemistry in the next few weeks
<lupo__> :-/
<jamest> reinhard: wouldn't that return cause the for dataSource in self.__details.keys(): to not make it thru all the items in self.__details.keys()
<reinhard> lupo__: I pity you
<lupo__> it's fun
<lupo__> but also a lot of work
<reinhard> jamest: you're right
<reinhard> jamest: perfectly right
<reinhard> jamest: it should be a "continue"
<lupo__> and anyways, i have done all my duties till end of septemberg
<reinhard> jamest: fsck, what a silly but!
<reinhard> bug
<jamest> well, you want to fix my fix :)
<jamest> or should i
<reinhard> can you commit it?
<jamest> sure can
<jamest> 2 jamest commits in less than a month
<jamest> sarge released
<jamest> maybe it is the end times
<lupo__> then viva voce
<reinhard> jamest: lol
*** jcater has joined #gnuenterprise
*** titopbs has quit IRC
*** titopbs has joined #gnuenterprise
*** lupo__ has quit IRC
<chillywilly> lo
<chillywilly> jamest: hehe
<chillywilly> jamest: the sky id falling!
<chillywilly> is*
*** titopbs has quit IRC
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** yure has quit IRC
<jamest> something odd with the new datassources
<jamest> some of my data in my custom apps is returned as '1'
<jamest> seems to be at random
<reinhard> you mean, it returns '1' instead of the real value?
<jamest> yes
<jamest> i'm passing in a list of fields to DataSourceWrapper
<reinhard> what data type of underlying column?
<jamest> in the one I'm looking at one field is  a varchar(8) one is an numeric(9,2)
<jamest> one is a text
<jamest> other fields are fine
<reinhard> it returns '1' for all rows?
<reinhard> or just for some?
<jamest> i row
<reinhard> can you check whether the SQL statement isued is correct?
<jamest> 1 row
<reinhard> hmm
<reinhard> other rows are correct then?
<reinhard> which would mean the SQL is correct
<jamest> that's a level 3 right?
<reinhard> yep
<reinhard> the most important debug level of all :)
<jamest> ah
<jamest> what I think might be happening
<jamest> the order of the fields that i pass in via fields=('a','b','c') doesn't match the order of the sql statement generated
<reinhard> right
<reinhard> as the fields are stored as keys in a dictionary
<reinhard> (like they always were)
<jamest> but the return values seem to fall in line with what's being returned
<jamest> example:
<jamest> fields=('invoice_no',.............)
<jamest> but the first field in the select is a boolean that returns a 1 in this case
<jamest> which is what is mapped to the invoice #
<reinhard> oh
<reinhard> I understand
<jamest> darn,that's not it
<jamest> but that is what it's doing
<jamest> i find my invoice # is set into my subtotal field about in the record set
*** btami has joined #gnuenterprise
<jamest> my date_generated field is set to the billto_city field value
<jamest> so it is definately scrambling the field/value pairs
<reinhard> DBSIG2/ResultSet should handle that
<reinhard> ResultSet._query_object_ stores the __fieldnames
<reinhard> exactly in the order they were issued in the select
<reinhard> and ResultSet._fetch_ uses that __fieldnames list
<reinhard> do you use a datasource of type="sql"?
<btami> wow, just installed ubuntu (after XP collapsed again, and decided to not reinstall it on this box anymore) !
<dimas> :)
<btami> :)
<jamest> reinhard: yes, but not in this case
* btami (kids) has another XP box for games
<btami> bbl
*** btami has quit IRC
<reinhard> jamest: can you maybe check if in the _fetch_ function the __fieldnames list matches the list of fields issued in the query?
<reinhard> DBSIG2.ResultSet.ResultSet._fetch_ that is
<jamest> holy shit that's ugly
<jamest> this table has 60 fields i need
<jamest> in the fields=('field1','field2','field3') i had a 'field4,field5'  <- Note the missing 's means it's one field name
<reinhard> oh sh*t
<reinhard> that explains a lot
<reinhard> the sql of course returns 2 columns for that
<jamest> yes
<jamest> which blows the crap out of sequence
<jamest> but doesn't generate any errors
<jamest> so it would be capable of doing lot of damage
<reinhard> yes
<jamest> as the unbound fields (field4 and field5) still returns a value of None so the app goes along just fine
<jamest> reinhard: would the best way to fix this be to adjust the registerField to throw an exception if a comma shows up in a field name?
<jamest> or is there some other datasource magic in there now that would be better applied
<reinhard> I think GDataSource.referenceField would be the best place to check this
<jamest> er, sorry referenceFIeld
<reinhard> yes, there is no other way to introduce a field into the list other than referenceField
<jamest> anything other than comma that should be checked against?
* jamest wonders if period is also dangerous
<reinhard> space
<reinhard> hmmm
<reinhard> different idea
<reinhard> how about quoting all field names in the generated sql?
<reinhard> what would a select like this do:
<reinhard> SELECT "foo", "bar, baz" FROM table
<jamest> should blow up just fine
<jamest> with an invalid field name
<jamest> at least in postgresql
<reinhard> would you be fine with that?
<jamest> verified
<jamest> i would
<reinhard> ok
<reinhard> I like it better than checking for specific characters
<jamest> so that'd be in the buildQuery in dbsig2 still right?
<reinhard> working on it
<reinhard> but yes
<jamest> holy crap!  something didn't change!
<jamest> (you should do something about that :)
<reinhard> well
<reinhard> actually it would be in _query_object_ in dbsig2
<reinhard>     what = string.join (fieldnames, ', ')
<jamest> ok, that's better :)
<reinhard> is what we have now
<reinhard>     what = '"' + string.join (fieldnames, '", "') + '"'
<reinhard> would seem logical at first
<reinhard> however that could still break with fieldnames containing " characters
<jamest> yes
<jamest> what kind of a server would allow " in the field name
<jamest> as i'm pretty sure that's reserved in SQL
<reinhard> ok, I'll commit this then
<reinhard> jamest: please test
<reinhard> (fix is completely untested)
<jamest> ok
<jamest> um
<jamest> one minor thing
<jamest> string.join is depreciated in 2.4
<jamest> i know we require only 2.3
<reinhard> what?
<jamest> but I think all of the 2.3 series will also accept the 2.4 way
<reinhard> string.join depreciated??
<reinhard> we must fieldnames.join() now?
<jamest> almost all string functions are
<jamest> no
<jamest> something like
<jamest> ','.join(fieldnames)
<reinhard> ah yes
<reinhard> that way around, right
<reinhard> i remember
<jamest> http://www.python.org/doc/2.4/lib/node107.html
<jamest> i've started converting my code as I hit it even though i run 2.3
<jamest> so figured i'd bring it up here as something that might be worth concidering
<reinhard> nice
<reinhard> we only use string.join 148 times in gnue
<mnemoc> :)
<reinhard> thanks for telling
<reinhard> I'll add it to my code cleanup checklist
<jamest> reinhard: it's any string functoin though
<jamest> which we probably use others
<reinhard> actually it boils down to "don't import string"
<reinhard> doesn't it?
<jamest> pretty much
<jamest> i think there are 2 or 3 functions still in that module
<reinhard> ok
<reinhard> added to my list
* reinhard considers writing up that list as a technote
<reinhard> as it contains quite generally useful "guidelines" like
<reinhard> write docstrings
<reinhard> document exceptions
<reinhard> foo vs. _foo vs. __foo vs. _foo_ naming
<reinhard> public functions before private functions
<reinhard> etc
<reinhard> just all those things I regard as "code cleanup" whithout any functional change
<jamest> i think that is a good idea
<reinhard> bbl
*** johannesV_ has quit IRC
*** SachaS_ has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** ayers has quit IRC
*** ayers has joined #gnuenterprise
*** SachaS_ has quit IRC
*** ayers has quit IRC
*** kilo has joined #gnuenterprise
<reinhard> good night all
*** reinhard has quit IRC
*** SachaS has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** sjc has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** yure has quit IRC
*** jcater has quit IRC
*** sjc has quit IRC
*** titopbs has quit IRC
*** kilo has quit IRC
*** ajmitch has joined #gnuenterprise
*** SachaS has quit IRC
*** mnemoc has quit IRC
*** mnemoc has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** ayers has joined #gnuenterprise
*** holycow has quit IRC