*** jcater has quit IRC *** johannesV has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** sjc has joined #gnuenterprise good morning all johannesV: did you read the logs? I think it could be better to not have a default for --connection in gnue-schema so "gnue-schema file.gsd" doesn't do anything except say something like please use --connection to operate on a database or --output-file to create a file hmmm still not sure hi reinhard on i haven't read logs yet i've updated my sarge :) johannesV: congrats ;) and, wow, i got 75 mb actually gnue-schema has operated on connections for 4 months only 75MB? although i did an upgrade yesterday :) aha so this 75 are only since yesterday afternoon maybe gnue packages will someday get into sarge ;) ajmitch_, i hope so ! I think jeff may have been busy today the ones currently in sid are the same as in sarge and are a bit out of date reinhard, could it be there's something wrong with closing connections ? but I've got packages for the latest release of all gnue tools (common,forms,designer,appserver,reports,nav) any that I've missed? i think this is a complete list of tools good reinhard, seems like the new gtk.ComboBox widget could have multiple columns in the dropdown (like a mini-grid) (but GF* won't support this [by now]) anyway, if i start forms now using gtk2-driver i (what a surprise) get some DeprecationWarnings I think we can (and have to) live with that for a wile I think we can't require the newest python-gtk2 already what is wrong with the closing of the connections? you've said you have *very old* open connections ... ? johannesV: no, you misunderstood just a sec ok back from phone johannesV: if you read the logs, jcater nearly got a heart attack when he called gnue-schema ah, ok i'll read logs now and recognized that it operates directly on a db without confirmation and then i said gnue-schema operates on connections for 4 months now also, I'm not sure if jcater is aware that gnue-schemal will *never* destroy any data ok, sorry, jcater for stealing a few heart-beats ... and whether he still would see the need for a confirmation if he knew that *** holycow has quit IRC basically the worst thing that can happen is you end up with some columns and/or tables you wouldn't actually need hmm and having changed indices actually gnue-schema can drop and recreate indices drop indices? yes, drop indices say you have a class having an index on 'name' then you change the gsd giving an index on 'bar' column, removing the other index so the name-index will be dropped (since it could interfere with the new ones) ok i wasn't aware of that i thought it to be not a good idea to 'cumulate' all indices ever defined on a class ... anyway (and same applies to constraints as soon as constraint-introspection is done) *** kilo has joined #gnuenterprise i think we should have a short talk with jcater before we change something wrt gnue-schema right leaving the connection-default is not very usefull at all since output to a file also needs a connection (how should gnue-schema check for existing relations if not using a connection?) which sql-dialect should it use to create the code for ? all this stuff is derived from a connection so i kinda like jcater's suggestion of an '-y or --auto' switch I think it's about time I split up the forms package, once this one gets into sid & sarge split into what ? gnue-forms-gtk2, etc instead of just gnue-forms-wxgtk :) since it's annoying to want the gtk2 forms driver & having to follow the Recommends: manually not everyone wants the wxpython libs installed for forms right, me for example :)) yep the forms package is named wxgtk because that used to be the only working driver :) now we at least have gtk2 & curses to use right I don't want to split gnue-common though ;) good morning far too many db drivers possible in there * ajmitch_ still has to fix that wishlist of creating a connections.conf with debconf :) good morning kilo just reading commit mails. what is the effect of recent changes on blocks? kilo: say you have a class with calculated fields to get the current value of such a calculated field you would have to fire a commit, right ?= (or at least execute a procedure) now you can just do "myBlock.update()" and you have all calculated fields up to date --- withouth doing a commit (this performs an implicit post () on the current record set) ah, got to try that. now i do call a calc poperty to get it calculated, so guess it could be easier now right, much easier then (at least i hope so) and i did another change yesterday regarding triggers have you seen that ? another side-effect of that update () function is: OnChange triggers get fired (on the class) this means you can use a forms-change-trigger to fire an appserver-OnChange trigger by doing a block.upate () even if the class has no procedures oh. triggers. yes. in fact i did not have a problem with them so far. never had a problem with a trigger. never. they always worked as i thought... * kilo sometimes forgets too soon *** btami has joined #gnuenterprise * johannesV back well i thought a gfd is much more readable if *large* trigger-code is at the end of the file large trigger code should be imported imho if that worked from where ? ah, i haven't commited that change ? but anyway - importing from other gfd does *not* solve the problem since one would have to create all that stuff around, like ... in order to import a simple trigger and it introduces another 'file' (which is another source of errors then) likewise if you put trigger code out into a python-file, you loose the namespace yes, putting it to a python file would be best no, i don't think so how would you then use a form's block in that code ? does importing triggers work now? i can commit a fix making it workin that would be great ok, gimme another 5 minutes then .. isn't 4 enough? 8-)) actually it would be, but you'd like me to test it, don't you ? consideration: 23 secs, implementation: 38 secs, test: 81 secs, commit message thinkup: 143 secs ok, got it it was 6 minutes... 8-)))) have i done too much testing then ? :) maybe 8-)) and now for something completely different .... do we have a concept of 'delete cascade' ? if i'm in the master record and press 'delete' button ... funny exceptions occur ah, and i've got another suggestion for tuning GFBlock :) what about a function called 'findRecord' ? which uses the block's current resultset's findRecord ... e.g. you have a block with a resultset and you would like to set that blocks current record to the record (in the resultset) having a field=value one would now have to iterate over the block using firstRecord () and nextRecord () *** kilo has quit IRC and checking all fields *** kilo has joined #gnuenterprise i think this is just what the resultset's function "findRecord()" is doing by now of course i can create another new resultset using the block's datasource but then i'd loose the already built resultset i cannot follow and, what i dislike more, i'd have to do another query reinhard, what do you think about ? I think I remember reading "search within resultset" somewhere in a TODO but don't remember where * ajmitch_ wonders if there's a new release of anything yet ;) we could expose the _currentResultSet of a block in it's trigger-namespace an thus give a trigger complete access to the current resultset of a block johannesV: I see a drawback in adding too much into the trigger namespace johannesV: could you plz show your test case, the file from where you imported a trigger? that means you have to be compatible on the complete interface of the ResultSet or you break existing triggers in existing forms kilo, :) as i've said, it's not worth very much ... trigger import could be very handy for me kilo, just a sec oh no, you again asking for more time. i feel serious bugs in johannes_time_management.gcd... 8-))) ok *** wt has joined #gnuenterprise so first you have to have a 'normal' gfd file with a trigger like this is for example in "src.gfd" in "other.gfd" you add a line but be aware, you cannot do this in a button ... so is not valid because GImportItem class has no method 'associateTrigger' .. not on a button... AttributeError: GImportItem instance has no attribute 'associateTrigger' but what you could do in this case is something like ... (please read above ....) it is not in a button same applies to entry ... field ... and the like you would have to import the trigger as 'normal' trigger and then reffer to it via src=".." it would be an On-Activation trigger right same applies to this On-Activation will be associated with the form but i can look if we can short-circuit GImportItem to do this for us ... hmm, actually i don't like this ... I'd need to add GTrigger to GParser .. right, ok. it works. great! thank you np kilo, whazzup? kilo, I have a question just made up a sketch of supply chain, csee http://gnuenterprise.org/packages/scm.php what does a person do if they don't want to keep an inventory with your item? for instance, say I do a job and need 3 screws and I buy those screws when I need them kinda like JIT but I don't want to track inventory in gnue can I do that? and what is the problem? it is the organization's own responsibility what should and must be tracked in an inventory I just wanted to make sure that your item didn't make that assumption kilo, did you like the direction of the .gld? basically yes I wish that it were easier to translate the .glds maybe compile .po files to glds? hmm, kinda TM as to my 'delete cascade' problem: of course we can do this, just add a 'OnDelete'-trigger to the class (in gcd) johannesV, another stunning insight by the developers of GNUe * wt pats you all on the back bbl *** btami has quit IRC python 2.4 released heh, just wanted to tell that too assignment to None gives syntax error... reinhard: do you have gnue-contrib checked out? not too current * reinhard is doing some customer work at the moment ok, plz tell when you have time kilo: depends on how much time 5 mins ok shooh shoot in the LOC module i have a Country and a Region class. Both have a calculated property named 'formatted' ok if i have a block on the Region, I would like to display LOC_country.LOC_formatted, ie the formatted name of the country ok but it gives back the formatted name of the Region that looks like a bug and even, from an outer module, say PARTY, i can nott access a country's formatted prop it tells me ther is no LOC_formatted property of PARTY_Party in the 'formatted' prop i have code like this: return self.LOC_name and as far as i can see it, 'self' is not handled correctly Region has 'LOC_formatted' prop, so it can find it (although a bad one) but Party does not have a LOC_formatted, so it gives error how should it work? already found the bug johannesV: in geasInstance, line 215 value = self.call (propertydef.procedure, None) this is the wrong "self" for class foo (calculated) property bar.baz self here is foo instead of bar so it really calls foo.baz instead of bar.baz imho at this point something similar to __findInstance in geasSession would have to be done ah, great, thx reinhard actually only the last line of __findInstace but I'm too unsure to dare to commit it ok, if johannesV can do it, then its ok. but then i can be sure that it is a bug, not my limit... yes it is a bug hmm so i've to look into geasInstance now ? :) probably :) kilo, where can i test it ? *** jcater has joined #gnuenterprise johannesV: gonna send you a gfd to test it i've added the fields to LOC_Region.gfd and it looks like the procedures are executed properly ... ? will try the gfd you've sent me if you choose a region, it should display the country the region is in ah, so you're using fk then but now it displays the region's name i can't follow ask *** sjc has quit IRC which field in LOC_Zip.gfd is wrong ? fldLocCountry it displays the region's name instead of the country's name no it is displaying the countrie's name (actually the formatted name) ah, wait and if you look at loc.gcd in gnue-contrib/gnue-invoice, you see that it is the Country class' formatted prop that should display the name now i get it Region's formatted prop should return the region's code it's quite tricky then cause i've changed your procedure code for country.formmated: return "Country: %s" % self.name it is the 'self' that is not interpreted ok so it looked to me as if it's that one, but the *name* inserted is the name of the region right yes, tricky ok, now i'll try to fix this good testing kilo ! it all originated when btami wanted to put the buyer's address on the report... and doing INV_buyer.PARTY_address.LOC_zip.LOC_formatted returned nothing /msg universe 15 mins gone by and johannesV is not ready yet. it must be a severe one... 8-)) no, have fixed it already but i'm not sure if it's the *right* way to solve the problem only joking bbl *** kilo has quit IRC ok, now it seems ok johannesV: not perfect not perfect enough for appserver ;-) it won't work for a fishhook (where the referenced class has the same classname as the referencing class) *** jamest has joined #gnuenterprise i would recommend to put that creation of the new geasInstance somewhere at the end of the existing for loop in a way that it only gets called if the for loop was done at least once like if ... for ... ..... x = geasInstance()... else: x = self ? yeah good idea i would have put a x = self before the if but your solution is cleaner (and of course i'm not seriously proposing to name the variable "x") you don't like that classdef.fullName != self.__classdef.fullName ? yes that can *happen* to be equal for a fishhook hmm that's right it would be just another gnue_id then so if i had taken my first implementation ... hrm i'd just enclose the for e in elements [:-1]: loop into if len (elements) > 1: for..... ref = geasInstance (...) right it's already done did it exactly that way :) ok, now i've some strange behaviour regarding commit then ... has to get a cup of coffee first ... *** lxf has joined #gnuenterprise ok, now i know what's happening i have a master-record, and 5 detail-records a calculated prop of the master calculates a sum of all detail-records after commit the sum doesn't get updated why ? because the master is committed *first* well, first of all the master needs to be posted before the details, to avoid ref.integrity probs (and then reloaded) this leads to a reload ... which fires the calc.field and *after* that the details are committed yeah damn so i think i should really tweak session.find so actually that wouldn't help much here well, of course because also the post runs in the same order that doesn't matter cause the find started in the master's proc, will find the detail-recs (pending) in the same session so it hides the prob they will not yet have arrived at the appserver at all at that time or am i wrong here? hmm that's a point will have to check no, i think they won't the client (forms/common) would have to again update the master after it has posted the details yes *** johannesV has quit IRC *** johannesV has joined #gnuenterprise woohoo I'm actually gnue'n hell must've frozen over w00t :) *** wendall911 has joined #gnuenterprise jcater: as to gnue-schema operating on a connection gnue-schema will never change or delete existing columns and never delete existing tables were you aware of that fact, and if no, does it change your opinion that there should be a user confirmation? (just to make sure) reinhard: I just think it is bad form to touch production data without some sort of verification *** btami has joined #gnuenterprise hi all that's just my opinion though, not sure what others think derek: DCL DCL DCL DCL DCL DCL reinhard: it will also insert rows into a table jcater: yes, if there are elements btami: howdy jcater: just committed into Char but have to go hope you will improve it more :) bbl *** btami has quit IRC btami: damn too quick jcater: i agree if nothing else than to stop me from doing bone headed stuff like accidentally updating a prod database not that I've ever made that mistake nope, never......look something shiny! ok reinhard: are you against it? or just playing devil's advocate ? I already put it on johannesV's todo list i need a johannesV! just wanted to make sure you didn't misunderstand gnue-schema's function jamest: I will add stuff to your TODO if it'd make you feel better reinhard: it has changed :) gack! I don't want to be a johannesV i want a johannesV ah well you can add stuff to my TODO list if you'd like that doesn't work i've tried I let my users add stuff to it of course, it's symlinked to /dev/null *** kilo has joined #gnuenterprise btmai: had major hardware failure on my mail server, will get to DCL when that is done also trying close on 25 million dollar 65 acre soccer complex by friday... so GNU Enterprise time very limited for at least a week *** ajmitch_ has quit IRC bah I woulnn't pay a penny more than $24m wow derek musta got a raise and I'd make them throw in an extra water fountain * jcater is hard-nosed like that of course now that he's up to somewhere around 25 mini-derek offspring the backyard pool probably wasn't enough true dat mini-dereks * jcater shivers not sure who to feel sorry for the kids or the wife s/feel sorry/feel more sorry/ the wife she's put up with him longer well what is interesting is playing politics is starting to payoff with the wife? attempting to enter into partnership with town never tired that angle where they are giving the land and paying for all development of park our company will just operate the park appears we are down to 50/50 shot at this jamest: really? as there is only one other group you never tried the "you play marilyn monroe and I'll play John Kennedy" angle? if it goes will have interesting uses for GNU Enterprise :) not that it's ever worked for me didn't he get shot? in the head even :) yeah * jamest thinks he'll avoid that one but still ok "you be monica and I'll be bill" oooo that better? you mean like "you be america I'll be Pres. Bush" ? rofl I was about ot say that too *** lxf has quit IRC ewwww *** jamest has left #gnuenterprise *** lekma has joined #gnuenterprise *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** jamest has joined #gnuenterprise *** sjc has joined #gnuenterprise *** ajmitch_ has joined #gnuenterprise *** johannesV has quit IRC *** someon has joined #gnuenterprise *** someon has quit IRC *** wt has quit IRC *** jamest has left #gnuenterprise *** reinhard has quit IRC *** jamest has joined #gnuenterprise *** sjc has quit IRC *** kilo has quit IRC *** jcater has quit IRC *** wendall911 has quit IRC *** jcater has joined #gnuenterprise *** jcater has quit IRC *** holycow has joined #gnuenterprise