*** holycow has quit IRC *** johannesV has joined #gnuenterprise *** reinhard has joined #gnuenterprise for the logs: automatic creation of mysql-databases *does work* (i've added this feature last month i think) oh so there's no reason any more to not use mysql except that it's a crappy db ;-) *** kilo has joined #gnuenterprise *** btami has joined #gnuenterprise good morning *** dcmwai has quit IRC morning It's almost coffee time over there isn't it? aye I thought you two were joking in the logs when you said you work in the same office.... but your connect messages suggest otherwise johannesV: a question about yesterday's topic - why is a comment only 70 in lenght? we are 1.5 metres from each other... we thought it's enough space for a comment on a class or a property ... why not infinite lenght? or at least 255... poor James Joyce could not have used gcd this way... Don't we lose some search efficiencies if we exceed 255? do you search on comments? Not at the moment, but I have an existing DB that has a field that has a limit of 255 chars... we search on it WAY too often Problem Tracking - Problem Description we tend to do ** searches... ah, that is another problem, searching free-form fields... Nods. and you can't index fields like that, since the indexes would continually be different. kilo: i won't introduce another blob-problematic field in *every* gnue_.... class i just feel that 70 is way too short. but the main problem is> why does interbase/firebird accept comment length>70... because it *stretches* the field-length on table-creation by the factor 3 so if you look at your db-schema you'll see it has a length of 210 instead of 70 this seems to be a firebird-specific thing shouldn't it only double it? Unicode uses two bytes per char, so when looking at it in a non-unicode way would be twice the number of bytes... yes, i thought so too, but kilo told us yesterday abouth that factor 3 (which is also true for my firebird-setup here) factor is 3, true. What does the data look like? Maybe it uses the third byte as a stop char.... but it should have been hidden from the outside world... i mean, you give it a string of length 10, then it should show it's length as 10, not 30 kilo: you can try to do a manual "create table foo (bar varchar(10))" and look at it afterwards who the fsck cares about how it stores it??? if it gives a length of 30 afterwards this is a bug in IB to me then But to most non-unicode systems, 1 byte = 1 char... so if it's unicode encoded, it would be larger internally... if the interfacing program doesn't know about unicode, it would read as 1 byte=1 char... yes, introspection should get back 10, not 30 * someon shuts up and tries to listen johannesV: where is the check on the comment field length? Does the length tripling happen for all DBs or just IB? interbase/firebird kilo: i've now checked this thing i've connected to firebird using "isql" and created a table with a varchar(10) field then i've started gnue-designer and looked at the length given by the introspection and it is "30" ah so, if a database has been created using "UNICODE_FSS" as character-set all lengths seem to be tripled How does isql show it when you do (the equivilent of) describe table i do have another instance (firebird) running which has been created using latin-1 and the same procedure results in a length of 10 (given by introspection) SQL> show table foobar ; BAR VARCHAR(10) Nullable funny... I wanted to put show table. so this point's out, that there is something strange in rdb$... (sys-tables) so isql reports it correctly but the isql driver for python reports 30? no, i think this has nothing to do with the python driver i think it's stored differently in rdb$* * someon doesn't know enough about IB/Firebird to be helpful :( *** someon has quit IRC johannesV: hmmm ok, running this statement: SELECT rf.rdb$field_name, tp.rdb$type_name, rf.rdb$null_flag, rf.rdb$default_source, fs.rdb$field_length, fs.rdb$field_scale, fs.rdb$field_precision FROM rdb$relation_fields rf, rdb$fields fs, rdb$types tp WHERE rf.rdb$relation_name = 'FOOBAR' AND fs.rdb$field_name = rf.rdb$field_source AND tp.rdb$type = fs.rdb$field_type AND tp.rdb$field_name = 'RDB$FIELD_TYPE' ORDER BY rf.rdb$field_name ; gives a field-length of 30 so there must be something to detect the factor which has to be applied to this length and, what is much more confusing although the show table foobar says it has a length of ten: this works fine: SQL> insert into foobar values ('a very long one') CON> ; SQL> select * from foobar ; BAR ============================== a very long one SQL> show table foobar ; BAR VARCHAR(10) Nullable SQL> *** wt has joined #gnuenterprise johannesV: it it kinda... horrifying well, at least it's not very clean ... and a bit confusing why can i insert a value with 15 characters into a field defined as length 10 bug in firebird? *and* why can i retrieve all those 15 chars ? or a feature ? :) one could say a feature .. *lo* btami was faster :) hehe kilo takes 3th place, he just stopped typing this :) * kilo was eating banana and trying to type with only left hand... banana time! 10 AM is banana time :) i have to go into kitchen, looking for a banana ... :) banana does not grow in a kitchen. it grows at the grocery 8-)) that doesn't matter ... i have a wife :) *lol* wife grows in kjitchen @weather EGPI @weather EGPH kilo: The current temperature in Edinburgh, United Kingdom is 43°F (8:50 AM GMT on November 30, 2004). Conditions: Clear. Humidity: 81%. Dew Point: 37°F. Pressure: 29.71 in (1006 hPa). UV: 0 out of 12 @weather LHUD kilo: The current temperature in Szeged, Hungary is 37°F. Conditions: Light Drizzle. Humidity: 97%. Dew Point: 36°F. Wind: NNE at 7 mph (11 km/h). Pressure: 30.12 in (1020 hPa). Visibility: 1.0 miles (1.2 kilometers). UV: 0 out of 12 I'm not sleeping again lucky me I have to be up in 5.5 hours hi wt hi *** wt has quit IRC *** wt has joined #gnuenterprise 5 hours is long... *** wt has quit IRC *** btami has quit IRC *** dneighbo_ has joined #gnuenterprise *** derek has quit IRC *** kilo has quit IRC *** jamest has joined #gnuenterprise *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** havoc has quit IRC *** sjc has joined #gnuenterprise *** jamest has left #gnuenterprise *** havoc has joined #gnuenterprise *** nickr has joined #gnuenterprise *** dneighbo has quit IRC *** btami has joined #gnuenterprise *** jcater has joined #gnuenterprise *** holycow has joined #gnuenterprise *** someon has joined #gnuenterprise quiet in here this time of day.... *** holycow has quit IRC *** holycow has joined #gnuenterprise *** holycow has quit IRC *** someon has quit IRC *** holycow has joined #gnuenterprise *** johannesV has quit IRC *** johannesV has joined #gnuenterprise btami: beware I'm starting to use the Char driver reinhard, if i add a 'post' function to the GFBlock's namespace, which does a post on the datasource's currentResultset (if there is one) this works fine for all calculated fields getting displayed in the form with all their new values but, the switchRecord (0) after calling post 'disables' the commit-toolbarbutton (i can still press F6 though to commit) but i think forms should distinguish between a post and a commit on the current resultset johannesV: this goes to deep into forms "philosophy" as that I could clearly answer it I know that common distinguishes between a post and a commit and that forms does not at all but I don't know the rationale behind that that's right iirc, it doesn't "distinguish" (or didn't ... it may now) between a post and a commit it's just that we had to handle the logic in two different palces to handle multiple datasources i.e., from the standpoint of a client tool, it was a "commit" but common, to get it to work right, had to internally post then commiyt granted, it's been a while since I was in the internals so I may be remembering this incorrectly jcater: I think you're pretty correct here i was just wondering what's happening if i add that 'post'-feature to gfblock the issue we are dealing with now is that appserver has the concept of calculated fields i.e. values that result from other values to get the correct calculated values, one has to "post" the other fields to the appserver without "committing" because the user doesn't want to commit yet and don't forgett the dialog-concept, where one could start a dialog form displaying a subset of field of the current record, modify and post them (not commit) reinhard: that's tricky I see the problem yeah jcater: we do a lot of tricky stuff nowadays ;-) I don't know what to say as conceptually, this type of "post" is nothing like a "save" from a user's standpoint but a "Refresh any calculated fields" type of call I wouldn't know a clean way to differentiate though we would have to save state of the currentResultSet before doing the post and setting it back to this saved state-set afterwards so state of currentResultSet does not change (from pov of forms) hmm i could try this right now ... this is appserver-specific, right? not exactly not really ... it could happen in 2-tier if there are triggers in the db that you would want to get fired before commit I see where you are coming from but I have no idea how you'd present that difference to the user I have a hard enough time getting them to grasp commit and clear so wouldn't want to introduce another layer to users I don't think the user would *see* that at all johannesV and me were thinking about a function that, say, a focusout-trigger could use reinhard, we could circumvent this by adding a special method called '__update__' to appserver's db-driver so one could do blkFoo.call ('__update__', {}) with one little difference, where this method-call does not perform the real session.call () but everything else, so state-information get's preserverd (btw. it's working well this way :) hrm this looks quite hackish to me indeed it is I think I would prefer blkFoo.update() or whatever other name this function would get doing what ? but otherwise doing exactly what you propose, actually and only being available for appserver (like call() is now) is it ? AFAICT callFuncOfCurrentRecord is not implemented for any other dbdriver so we could well define a new chain of functions from the block down to appserver's dbdriver for update() ok parallel like call -> callFunc -> callFuncOfCurrentRecord -> don't remember what it was then however if jcater (or jamest for that matter) see this as something that should be solved in a more general way (not appserver-specific) I'd surely be open to that, too but my experience is that jcater and jamest prefer solutions that don't affect 2-tier ;-) ok, have to leave, my machines are shutting down 22:00 *** johannesV has quit IRC *** btami has quit IRC *** kilo has joined #gnuenterprise *** jamest has joined #gnuenterprise *** jamest has joined #gnuenterprise *** sjc has quit IRC *** sjc has joined #gnuenterprise *** reinhard has quit IRC reinhard: if you read the logs... I just used gnue-schema for first time in a while didn't know it changed from by default, writing to a .sql file to actually writing to a database imho, if this is going to be the default then the program should at least ask for a confirmation before writing to database as that could really do damage to a person not paying attention "I am about to update your database. Continue? " you could still have a --auto (or -y, like apt-get has) to not ask so if used from scripts, or appserver, it doesn't ask my heart actually skipped a beat when it said it was altering my database :) (luckily it was test database) *** sjc has quit IRC *** jamest has quit IRC *** kilo has quit IRC *** holycow has quit IRC *** jcater has quit IRC *** jamest has joined #gnuenterprise *** wendall911 has joined #gnuenterprise *** wendall911 has left #gnuenterprise *** holycow has joined #gnuenterprise *** jamest has left #gnuenterprise *** jamest has joined #gnuenterprise *** jcater has joined #gnuenterprise *** jcater_ has joined #gnuenterprise *** jcater has quit IRC * jcater runs *roh* *roh* dereks in the house *** jamest has quit IRC *** havoc has quit IRC *** Vee has quit IRC *** agile has quit IRC *** ncjp has quit IRC *** ajmitch_ has quit IRC *** Morphous has quit IRC *** involved has quit IRC *** dimas has quit IRC *** ajmitch_ has joined #gnuenterprise *** dimas has joined #gnuenterprise *** ncjp has joined #gnuenterprise *** Morphous has joined #gnuenterprise *** involved has joined #gnuenterprise *** ncjp has quit IRC *** ncjp has joined #gnuenterprise *** havoc has joined #gnuenterprise *** Vee has joined #gnuenterprise *** agile has joined #gnuenterprise