meow- (~meow@212.199.197.123) left irc: Read error: 104 (Connection reset by peer) meow- (~meow@212.199.197.221) joined #gnuenterprise. psu (psu@manorcon.demon.co.uk) joined #gnuenterprise. Gedanken (~schatten@dv101s49.lawrence.ks.us) joined #gnuenterprise. dres_ (~dres@mail.lewismoss.org) joined #gnuenterprise. dres (~dres@mail.lewismoss.org) left irc: Read error: 104 (Connection reset by peer) heh thought Derek would be up for the match psu (psu@manorcon.demon.co.uk) left #gnuenterprise. Gedanken (~schatten@dv101s49.lawrence.ks.us) left irc: Remote closed the connection robbie (~I@dg-5-p32.winshop.com.au) left irc: Read error: 113 (No route to host) damn where is psu USA kicking ass!!!!!! early goal and just blocked a penalty kick!!!!! Action: dneighbo is not going to be able to sleep tonight :) Nick change: Grantbow -> Beutelgeuse Nick change: Beutelgeuse -> Grantbow ariel_ (~ariel@ppp-217-133-245-161.dialup.tiscali.it) joined #gnuenterprise. alexey_ (~Alexey@195.151.214.33) left irc: "[x]chat" pattieja (~pattieja@sc2-24.217.184.48.charter-stl.com) left irc: Read error: 113 (No route to host) grrr Action: dneighbo hates bruce arena, butthead tried to sit on a goal in hopes it would hatch at least we got one point :( as we were definitely out played nightie night mgedmin (~mg@bit.codeworks.lt) joined #gnuenterprise. Action: dneighbo is away: bed hi mgedmin hi you work for m? yes you guys get things installed? what kinds of things? GNUe we built debs for gnue common, forms and designer 0.3 cool i think 3 other people were working on them as well Action: dneighbo didnt know that was something you all were looking at if you post them and source others can help polish up i should probably put the changes we made somewhere one moment and we can give them to our debian maintainer so you can see them in sid(unstable) its late here 1:34 i was just getting ready to go to bed, but noticed the .lt domain did you have any questions before i run off? actually, yes I wonder if someone's working on problems with PostgreSQL numeric types what is the problem (SQL errors like "operator = not defined for numeric and double") (when trying to update a record containing a numeric field) do you have a sample form? I think I saw a message somewhere in the mailing list archives (can't remember exactly) and what postgres driver are you using psycopg actually the form you sent m as an example has this problem as well Action: dneighbo always hates that half the time its our fault and half the time its bum db driver :) what postgres driver were you using? psycopg can you tell me what field in the form i sent you has the problem? if you try to update a field in the employee table, postgres complains Unable to identify an operator '=' for types 'numeric' and 'double precision' ok in the form i sent m? basically postgres wants explicit typecasts in statements like UPDATE employee SET foo=bar WHERE numericfield=123.4::numeric we also found that using UPDATE employee SET foo=bar WHERE numericfield='123.4' works too, but I'm not sure that's portable enough across databases you have lost me now okay please we must start at the problem, not what we think the answer is I run gnue-forms codeworks.gfd select a department that has employees change the title field click "save all" and I get an error message at that point postgresql 7.2, psycopg 1.0.8 ok give me like three minutes to update cvs and create the sample db and such and i will get you an answer ok error is recreated here are you using cvs? or the official release? Action: dneighbo thinks someone has introduced a bug in cvs OR the pyscopg driver in sid has been changed as when i ran this form before sending to m this problem didnt exist Action: dneighbo is investigating btw: it appears the problem is AND department='1' i.e. department on the employee table should not have '' around its value hm currently I'm looking at the error message produced by 0.3.0 but afair the same happened with cvs version on saturday the error message here reads ERROR: Unable to identify an operator '=' for types 'numeric' and 'double precision'\n You will have to retype this query using an epxlicit cast Retrying the same SQL in psql results in the same error using correct same error i get but look at the query the last part will say AND department='somenumber' yes if you take that query and remove the '' around somenumber afer deptarment= i bet the query works in postgres don't think so quite the opposite it appeasrs someone has foobared the driver if we add '' around salary it starts working i'll doublecheck in a second yep, salary='400.4' works salary=400.4::numeric(9,3) works too plain salary=400.4 doesn't hmmm something has changed here it's a PostgreSQL issue I think Action: dneighbo cant get to work box from here but im 1000% positive this worked when i sent m the form and that was with our 0.3.0 release yes Action: dneighbo has old postgres box here you have a minute i can try on it I've got all day it's morning here ;) its morning here too, EARLY morning :) Action: dneighbo impatiently waits for laptop to boot derek (~derek@cpe-24-221-112-50.az.sprintbbd.net) joined #gnuenterprise. hahah now there is two of me #gnuenterprise: mode change '+o derek' by ChanServ!ChanServ@services. btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. I'm looking at a PostgreSQL book atm hello Action: derek is waiting for cvs to update on the laptop hi btami hi derek hello looks like PostgreSQL wants a typecast when it sees a numeric type in the WHERE part grrrr i get this on older box too cvs i swear this worked at the office Action: derek goes to look at something it works fine when you try to add new records it fails when you try to update them or perform a query (no error messages, but no results either in that case) maybe i didnt try to update one i coudl swear i changed a salary though to test we found a workaround in DBSIG_DataObject._toSqlString replacing elif type(value) == types.FloatType: return str(value) with elif type(value) == types.FloatType: return "'%s'" % str(value) seems to help thats where im looking now :) BUT how does that affect otehr db's I don't like that though i.e. if it chokes other db's it needs to be in the postgres driver and not DBSIG the Correct(TM) way according to PostgreSQL would be to return "'%s'::numeric(foo,bar)", where foo/bar depend on the schema oops s/'%s'::/%s::/ although using just ::numeric seems to work fine too (for numeric fields -- didn't test with floats etc) basically we do not need a solution right now, I just wanted to check if this problem was known please submit this as a bug to common-support@gnuenterprise.org go ahead and attach your 'patch' (although its not good long term solution) and cc: info@gnue.org i.e. this was not known problem okay we should be able to produce a patch in the morning (your afternoon) I still don't feel comfortable with GNUe (ie don't know all the correct places to report problems etc) i.e. official patch worse case we put in the return "'%s'" until we can find a more elegant answer btw: here is what broke it http://subversions.gnu.org/cgi-bin/cvsweb/gnue/common/src/dbdrivers/_dbsig/DBdriver.py.diff?r1=1.48&r2=1.49&f=h elif type(value) == types.FloatType: return str(value) was added 10 days ago my box at work has cvs from more than 10 days probably not the 0.3.0 release so i bet it was working there Action: derek really was starting to think i was nuts it looks like jason was trying to fix an integer problem i wonder if there is a types.IntType or something Action: derek wonders if you change salary to INT if you have the same issue i want to experiment a bit with ints and floats before submitting a bug report ok ints work fine change salary from numeric to int in the .sql file and rerun it and form works fine so jcater hit an int and it blew up so he removed quotes which fried the float er numeric type so need to find docs to see about types.XXXX there should be IntType and also LongType IIRC to see if way we can isolate better to int instead of all number types BTW PostgreSQL accepts queries like "salary <> 100" but barfs on "salary <> 100.0" yeah i think it has to do with the . Yurik (~yrashk@gw.telcos.net.ua) joined #gnuenterprise. mgedmin: there are a few things happening here that i can see that are issues best to address in the morning example: when i turn the db field to int the form appends a .0 to it that causes issue which i think is really the problem i.e. jcater introduced a patch that says 'fixes integers' i assume he had to do thsi because he was using forms type 'number' and it was appending the .0 which was hosing up integers or somethign multiply that by # of different DBMSes, and different data types... yep this doesn't look like a trivial problem i dont think its too bad really i think its the UI entry widget that is causing the issue honestly the value has to be used in an SQL statement somewhere mgedmin: let me explain what im seeing in the form the entry is defined number so regardless of if the db is int or float its appending a .0 (if no decimal is defined) the type(value) isnt checking the DB field type its checking the string contents OTOH the choice between 1.5, '1.5', 1.5::numeric depends on the DB/schema, not on UI so that field will ALWAYS be float regardless of whether its int or not we need to fix that because if we fix that its a trivial problem as you can if if type(value) == type.IntType or such do X the way we have this implemented you simply put the most COMMON instance in dbsig and anyone who isnt 'standard' you override in their driver so i dont think the different db's doing different ways is that big a deal its getting a way to define what the hell you actually are getting that has to be done :) i hope that made sense Action: derek really needs to go to bed its 03:00 and i have to be to work by 09:00 i will be back around then if you are still around send issue to email addresses i mentioned and tell them to reference irc log as well see you in the morning Action: derek is away: sleep see you sorry for keeping you up alga (~alga@bit.codeworks.lt) joined #gnuenterprise. morning ;-) I've a conceptual problem we're trying to do XP that involves unit testing and functional testing of all the code written the question is: how do we test forms? what to test in them? meow-_ (~meow@212.199.198.11) joined #gnuenterprise. hi alga i think this is not a trivial task yep so try ask jcater/jamest later OK Nick change: meow-_ -> Luminion Luminion (~meow@212.199.198.11) left irc: Client Quit i think unit testing require exact developer docs and this is not ready yet :) meow- (~meow@212.199.197.221) left irc: Read error: 110 (Connection timed out) we're ok with becoming gnue developers... i've an impression, you have to be a gnue developer in order to do anything really useful with gnue agree, but notice GNUe has only ver 0.3 hello all hi if someone is interested in Debian packages of GNUe common/forms/designer 0.3.0, I've made diffs available at http://www.codeworks.lt/~mg/gnue/ btami: but as I know tests in XP defined not upon developer's doc they should be defined on all steps of improving the code and the questions more how to use test packages (like pyunit?) with forms sorry, but i don't know to much about these just reading diveintopython yet nickr and jbailey are the main guys working on the debs at the moment, they are doing some things to try and make the install mechanism more generic ra3vat: pyunit is easily deployed, the problem is how to programmatically call/control the forms we had an idea to write a special UI driver for that purpose, but later we dropped that after all, we can always use the API the UI drivers use themselves actually, we with alga are still trying to decide what does it mean to 'test a form' ;) alga: ok, not tried it myself yet mgedmin: after testing some internals it should also simulate user interaction, is not it? mgedmin: do you also do a pair programming? yes Action: mgedmin is away: lunchtime Action: btami is away: lunch pair programming is the fun part :-) alga: really? glad to hear that. Is it 100% mandatory thing for XP? btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: Remote closed the connection Yurik (~yrashk@gw.telcos.net.ua) left irc: Read error: 104 (Connection reset by peer) Yurik (~yrashk@gw.telcos.net.ua) joined #gnuenterprise. ra3vat: it is ToyMan (~stuq@65.167.123.51) joined #gnuenterprise. Action: mgedmin is back (gone 01:29:28) btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: "Client Exiting" siesel (jan@dial-213-168-95-86.netcologne.de) joined #gnuenterprise. hello hi SachaS (~Sacha@dialup-196-110.wasp.net.au) joined #gnuenterprise. Action: Yurik is away: left neilt (~neilt@66.95.5.110) joined #gnuenterprise. #gnuenterprise: mode change '+o neilt' by ChanServ!ChanServ@services. mgedmin (~mg@bit.codeworks.lt) left irc: "Client Exiting" mgedmin (mg@bit.codeworks.lt) joined #gnuenterprise. siesel (jan@dial-213-168-95-86.netcologne.de) left irc: "http://www.blackened.com/blackened/" jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. Arturas (arturas@bit.codeworks.lt) joined #gnuenterprise. Hello hi hello Gedanken (~schatten@typhon.eecs.ku.edu) joined #gnuenterprise. does XP mean XP (like windows or cross platform or extreme programming)? re: other items, one should be able to do useful things with gnue w/o being a GNUe developer BUT i think they need to be a developer of some level to do something i.e. they shouldnt have to be a GNUe tool developer, but they should have application development experience re: testing currently i have like 3 forms i use to 'test' things as i find forms that 'break' things i try to shovel them into my 'test' suite i want to look at unit tester that will test functions of GNUe w/o actually running forms at some point we will need to build or find a free test suite to automate testing at this point its burden of effort issue i.e. not enough man hours extreme programming i think as more people start to bring GNUe into production the more important test suite will come true has jcater come in yet? derek, does it pay to test if the form can be loaded at all? i mean, do forms often break on load? um yes an no as stated before a release i generally run about 5 or 10 different forms automate tests are what XP starts from one is just simple no data form, with complex trigger dneighbo / dere: here jcater: can you read log re: db problem somewhat at least yeah, read it jamest just identified it it really p*sses me off that PostgreSQL 7.x can't handle implicit numeric conversions I mean, that's just down right backwards jcater: NO KIDDING erhm? something I'd expect from MySQL or something i about died when mgedmin What do you mean by implicit numeric conversions? Gedanken: 1 > 2.0 breaks it different types Action: jcater *somewhat* understands int to double breaking it jcater: i started a patch, but i think the entry is causing issues as it makes the value FLOAT no matter what but one floating point to another floating point? alga: interesting, I have never experienced that dneighbo: yes, python "floats" are used for all our internal number storage other wise you could just use the type(value) == type.FloatType trick BTW I filed a bug report -- see ticket #54 mgedmin: yeah, that was forwarded to me well let me rephrase that, postgres is the broken one here :) we originally had it always as strings i.e., "1.0" Gedanken: no it doesn't no it doesn't what? Gedanken: redev=> select 1 < 2.0; but that broke some databases it works ah So what does break now? select 1::numeric < 2.0; breaks in realistic situations, "select foo from bar where baz = 1.0;" breaks when baz is of type numeric something about that bothers me and I think it is more of the SQL then anything At any rate, adding an operator shouldn't be too hard well, adding an operator *may* not be too hard' it we have to do full-on introspection at form load time, that could be a big performance hit I am talking about adding an operator to postgresql oh Action: mgedmin too would like to hear something from postgresql side -- what is the purpose of this 'feature' the postgresql guys are pretty responsive, but Tom can be a dick some times Action: dneighbo hopes this is a postgres bug, but doubts it as i have postgres 6.5.x here and it does same thing frankly, my opinion of PostgreSQL just took a dive southwards as any "reason" they can provide is a technical one that *should* be hidden from SQL users Action: jcater is sure there is a "reason" behind it to me it makes NO sense either BTW, AFAICU forms currently perform the updates by constructing an SQL statement and listing *all* fields in WHERE clause. Is there a way to use only the primary key instead? yeah, that's something we need to look at if updating a queried record (and not inserting a new record and then updating it in same session), then the database's "row id" is used IF the database supports such a thing (I know Oracle's does) aditya_gilra (~aditya@61.0.108.254) joined #gnuenterprise. now what database wouldnt havve an oid? or uid? well ;) PostgreSQL 7.2 ? it used to have oid? from 7.2 and beyond, oid's are optional you saying they removed that they made it optional sigh there's no guarantee any more guess people do stupid things to 'compete' nah, it is perfectly resonable there's a slight performance improvement, iirc not all tables need OIDS .. BUT err, nevermind I won't go there OID wrap around anyone? ? i guess i cant think of a good reason to not have an OID the issue was that OIDs could wrap around and thus not be unique true every table might not need one BUT which kinda invalidates that whole OID thing thast like saying i might not ever need a spare tire so why bog my car down with the extra weight of course this was for databases of a really really large size, but ... it exists so we have a fix in the works for htis if so what ? (me is curious) to the approach I could see why a implicit conversion between type numeric and type float doesn't exist er ... non-implicit God Remembrance Soory to interrrupt well way i look at it, it doesnt matter much the numeric type is quite a bit different then float ... too much just to allow transient coversions postgres is a db people will be using, we need to support their quirks whether we agree or disagree with them from India we're developing a production system few queries can i ask? Gedanken: my only issue with that is other major databases do it implicitly aditya_gilra: sure Gedanken: BECAUSE it's a technical detail that the average user of SQL shouldn't be concerned with but it's a moot argument jcater: I can understand that, but I would to see their definition of the SQL types because the PostgreSQL has already decided to implement it that way :( so we must support it :( we're trying to change the list of values in a dropdown entry from a trigger jcater: well yes at this point in time you have two options: 1) work around it using implicit casts or 2) write the operators and submit it for inclusion to the postgresql team we're able to update a datasource from a trigger the block attached to that datasource updates itself BUT, a dropdown entry attached to a datasource does not update itself if we change the datasource via trigger eg. form.dtsAUTHOR_COMBO.createResultSet({"author_en":"Swamiji"}) aditya_gilra: correct, this is known issue Action: derek needs to file a bug for it (i might have already) oh wait you might be having different issue than what im thining thinking jcater: what if we made forms more descriptive? i.e. what if instead of 'numeric' for type cast we had 'float' (or double or whatever you want to label it) and 'integer' instead of just numeric? derek: I was trying ****really**** hard to avoid that as it goes into support issues I didn't want to deal with here's a small sample of the form I'm having problems with jcater: im not saying i like it but only way im seeing it other than is db introspection we dont have i18n working in forms yet do we? Arturas ? not in the .gfd part only in the tool right? Please note the trigger in entry inpOldCode It updates the form.dtsAUTHOR_COMBO datasource using a conditional dneighbo (~dneighbo@cpe-24-221-112-50.az.sprintbbd.net) left irc: "Client Exiting" Now note the dropdown entry inpAuthorTupleId which uses the datasource we updated in the trigger namely dtsAUTHOR_COMBO