*** Morphous has quit IRC *** Morphous has joined #gnuenterprise *** holycow has quit IRC *** jamest has quit IRC *** Morphous_ has joined #gnuenterprise *** Morphous has quit IRC *** SachaS has quit IRC *** johannesV has joined #gnuenterprise *** jcater has quit IRC *** SachaS has joined #gnuenterprise morning hi hi johannesV did you see my comment, that the encoding could be an option for the --createdb option ? yeah, but this is not really usefull since you cannot change the server-encoding ok. ;) i thought you can when you create a new database createdb -E UNICODE at least in Postgresql so you can have different databases with different encoding. not, we cannot change the server-encoding after the database-server has been setup thats what I read on a website really ? and this works ? ah oh yeah that is true. not without dropping the db and then creating it again. oh, sorry, you're right it seems to work for at least postgres, but i've to check that ok, for postgres it works so we would use the encoding given in the referenced connection from connection.conf not from a commandline argument oh ok. yeah. hmm is the encoding attribute in the xml directirve in the .gcd file only for the data in the XML file? but this is maybe not what i want * SachaS would think so since the connection.conf's encoding means 'client-encoding' not server-side one ok I am not sure how this should be handled. Its good that you know of the problem. I came across the problem when loading .gsd from the gnue-package ... i'd say --createdb just creates the database following the system-default now well, from which gsd ? one sec and maybe there's some automation later on *** kilo has joined #gnuenterprise *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise *** btami has joined #gnuenterprise hi all *** sacha has joined #gnuenterprise hello this is a test johannesV: encoding problem in file: gnue/gnue-packages/base/typedef/insert-en-currency.gsd in line 205 this is not a utf-8 character ! ó Ã³ the first is in gsd-file, the second would be utf-8 ! so if you add gsd-files, please make sure the given encoding (in ) matches the character-set used if i write gsd-files manually i'm doing it this way: LANG=de_AT.UTF-8; xterm & in this new xterm i'll open the gsd-file using vi and write it so i can just insert any special characters like umlauts and so on using the UTF-8 locale would automatically convert that characters into valid utf-8 sequences so opening this file using a locale like de_AT (.ISO8859-1) would show the proper utf-8 sequences :) hi all hi kilo hi kilo. johannesV: so what you say is that we have to change those characters in all gnue-packages to contain only UTF-8 characters. Or would it be better to have UNICODE in gnue-packages? you cannot have unicode directly in a text-file that's why we encode it in utf-8 johannesV: i think Sacha is right, re: need of server side encoding param for db creation we cannot say: 'this file is utf-8' and in reality it contains latin1 johannesV: what text files you talking about? i would go a step further and say: all databases created by --createdb are in unicode-encoding (if possible) gsd thats xml, isn't it ? gnue/gnue-packages/base/typedef/insert-en-currency.gsd stats in it's first line: ah, i see but has non-utf-8 characters like like 205: ó ok so this can't be (if encoding says utf-8 there must be utf-8 in it) but this doesn't solve the db-encoding problem i agree to use --createdb unicode-encoding if one sets up his database-server to only support (7-bit)-ascii-characters he've got a problem :) have to go, bbl yeah if the gnue-packages are utf8 and someone has its database server setup to only support 7bit ascii, then there is a problem. and the user gets a error message (probably from database backend) when gsscvs runs the .gsd file and tries to import the data into the database. kilo are you here? seem like we have to edit the .gsd files ;) SachaS: yes but what is the solution then wrt encoding to only have utf-8 characters in the gnue-packages this would have the requirement, that all gnue-package users MUST have utf-8 database encoding. what is the current version of gnue-packages? 0.0.1 ? so maybe we change all to utf-8 and keep it that way in the near time. well back later *** SachaS has quit IRC i dont get it... kilo: what are you missing ? *** Morphous_ has quit IRC *** Morphous_ has joined #gnuenterprise johannesV: my goldmine... 8-)) bbl *** Morphous has joined #gnuenterprise *** Morphous_ has quit IRC hi there. in case you didn't notice: the web access to svn at http://www.gnuenterprise.org/cgi-bin/viewcvs.cgi/gnue/trunk/ doesn't work... it says: "ImportError: No module named svn" *** Morphous has quit IRC *** Morphous has joined #gnuenterprise *** SachaS has joined #gnuenterprise derek: every considered to use emacs for your email? not sure if it supports imap... *** btami has quit IRC *** btami has joined #gnuenterprise * SachaS changed default encoding to UNICODE of the postgresql database *** mixi^ has joined #gnuenterprise *** mixi has quit IRC johannesV gsscvs is a great tool to do backup :) thanks. *** btami has quit IRC *** Morphous has quit IRC *** Morphous has joined #gnuenterprise :) np johannesV did you get my email? just arrived an invoice package could extend the workItem class with a isBilled property... what do you think? deltatime is a calculated field, isn't it ? what's chargin-rate ? how many chargingrate-entries are there per workitem ? yes deltaTime its a calculated field. there is one charging rate so why is there a 'class' charging rate if the relation between workitem and chargingrate ist one to one ? to make calculations on workitem's chargingrate more complicated ? ;) hmmm what's the purpose of a charging-rate ? it does not matter, does it?. Either there is a relation or the workItem class has a referenced property ... it does matter: you will NEED a JOIN ! 1 hour work multiplied by 10 US$ to calculate the cost of a work-item you have to join two tables no big deal is it? ;) if it's integrated into the workitem you won't have to ok. oh yeah i get it maybe not for a postgres right but what about other backends ? why create overload ? actually i have a deal how much one hour of work is worth actually i would belong to a project, sort of .... so each work item is related to a project so per default each work item will be charged at the rate stored in the project. does this make sense? ok, but then the charging-rate is a member of the class 'project' and yes, it makes sense yes. note: it's a member not a detail :) ok maybe i mix o mix something like i want to have a data type like the chargingRate has a currency and a number and maybe a description. so i was thinking this is done by a new class and then in the project class I can reference that class don't think of classes like c-structs ! they're not :) so far one project will have one charing rate... well thats what i mix up, it seems. yeah, i feel some of the gnue-packages-gcd's are built the same way just think of how to calculate an invoices overall-value ... :) if every item-price is a reference to another 'amount'-class which references a currency-class yes ... so you'll need a lot of joins to get such a simple value !!! i can think of a lot db's having trouble with such things yes I had this in mind so I could set the currency ID, plus the ammount in the work item class. or better in the project class right ok. so I wander if I create a new project I would need "logic" that makes sure that the user only puts a valid currency ID into the currency ID property of a project objec.t right? no, you just say 'currency' in the 'project' must not be null so you'll get a valid entry automatically and of what type is it? since you cannot select an invalid value base_currency ? or core_currency, don't know the base-packages so isn't that a relation? it's a relation to the currency you won't duplicate the currency like EUR, USD, CHF, ... so what is stored in the currency_id field? the gnue_id of that currency of the base_currency table? i don't know, as i've said, i don't like the core-classes anyway :) good you mention that :) speaking in terms of appserver "there is no class without a gnue_id" so if a class foo has a property of type 'bar' this is an implicit relation to the class bar.gnue_id field keeping that in mind, the currency-class (core_currency) has an implicit gnue_id field which will be referenced automatically if you set a property-type to 'core_currency' ok. i think core_currency.id is the short term of a currency like CHF or USD or EUR and a simple amount field in the work item would be sufficient and the core_currency.name is a long name like 'US Dollar' ... yeah i would think so too right so you would have project.currency (of type core_currency) which specifies the currency of amount yes. and a project.amount which gives the real value yes. this provokes another question sorry about that, please tell me if you dont have time... but - and that's the difference to your picture - both values are in the project-class and not in their one one s/one one/own one/ yeah i see that, was a bad example. no, was a good example so i point's out such things; normalization is good in principle i can imagine an own class for a chargin-rate makes sense if more projects reuse the same charges, and modifying one would affect all related projects in such a case you would introduce a seperate class for that ok. one more thing i want to ask. lets assume at the start of the project we agreed to use EUR and 10 as the charing rate. then after 5 months its changes to USD and 20 what are the common ways to solve these problesm? which problem ? like if i want go through all the work items and calculate a total but the first half of workitems are charged for 10 EURO and the second half of workitems charged at USD 20 if i just update those values in the project object i forget about the fact, that I have to calculate all work items from date x to date y at 10 EURO where as I have to calcualte all work items from date y to date z at 20 USD i guess this is a problem. so a silly idea is to have the correct currency and amount in the work item class. *** jamest has joined #gnuenterprise * SachaS thinks the described problem is repeated all over in different cases. * SachaS wonders what the common sense is how to model dbs accordingly *** johannesV_ has joined #gnuenterprise Sacha: which problem do you have with changing the rate ? that when i change the rate and currency i dont know which rate and currency i have to charge work items. you mean if it changes in a project ? yes. if it's varying you've to connect it to the workitem ok. you have to then to think if it makes sens in the project, maybe as default for workitems i.e. customer and invoice a customer has a ref. to the currency ik ok and if a new invoice is created for that customer invoice.currency get's initialized with the customers' currency bingo but is subject to differ from customer.currency btw. this case is a bit difficult to handle with appserver why is that? usually one would use the OnInit-Trigger of a class for that yes, thats what I would use. but forms/common fires the OnNewRecord event too late (namely on commit) and that's far too late we treat this situation as a todo atm but we're aware of it since it would need other changes in common/forms too damn, i've to leave again ... bbl so what you say is, that in the OnInit Trigger I cannot access the customer class? maybe a find() for the customer would get me the customer reference and then I could get the default currency. *** johannesV has quit IRC ok. see you later. back no, Sacha, you can access the customer class, but OnInit () is fired just before the commit is performed so it doesn't make sense to set values in the OnInit () because they would override the users's input so you could check if the user has set a value, and if not, then set them? well, this would work, but it doesn't solve the default-problem i would use OnValidate for such a thing anyway i would like to see such defaults (set by OnInit) when i press the 'new record'-button in my form otherwise i won't know there's default value oh yes. that would be nice. did the default value in the .gcd file go away? there hasn't been any default value did the default attribute in the property element of the .gcd file go away? no? no, there was no default ok. (it would imply a gnue_default in gnue_property-table/class) would it be good to have default values? in the .gcd file? hmm, maybe oh yeah your version of "new record" would be nice. to fill in default values into the form of the new record. i can imagine having defaults; such defaults would be introduced in an automatic call of a virtual OnInit () and currently the form does not communicate the "new record" button pressed to the appserver ... and further it would have to update the content of the new record as well ... ok i think i see the problem. *** jcater has joined #gnuenterprise Sacha: the 'new-record' event is processed to the datasource correct, but a new appserver-class-instance get's created on commit only so the OnInit event will be deferred until commit-time so it seems as if it could be solved in modifying appserver's datasource-driver where an 'insertRecord ()' does an implicit post () (to create the appserver-internal class-instance) but this doesn't work atm, because 'insertRecord ()' of a datasource (GFBlock) get's called too much times ! i think using the 'edit-record' button would be a help in this case or there is a way to prevent a form of automatically inserting a record into each block could you check if an insertRecord has already created a appserver-internal class-instance ? and only create one if it is not yet created... see you later *** SachaS has quit IRC *** Morphous has quit IRC *** Morphous has joined #gnuenterprise *** mixi has joined #gnuenterprise *** Morphous has quit IRC *** mixi^ has quit IRC *** Vee has quit IRC *** Vee2d2 has quit IRC *** derek has quit IRC *** Morphous has joined #gnuenterprise *** mixi^ has joined #gnuenterprise *** Vee has joined #gnuenterprise *** Vee2d2 has joined #gnuenterprise *** derek has joined #gnuenterprise *** mixi^ has quit IRC *** sjc has joined #gnuenterprise *** holycow has joined #gnuenterprise *** _holycow has joined #gnuenterprise *** sjc has quit IRC *** sjc has joined #gnuenterprise *** mixi has quit IRC *** mixi has joined #gnuenterprise *** SachaS has joined #gnuenterprise hi everyone SachaS, the solution is not changing appserver well, not only but to control when a GFBlock instance calls it's datasources insertRecord () a default value could be procedure or code? default="import mx.DateTime; return mx.DateTime.today()" ? if there are 'default values' in the future i think it's a value ok and everything else has to be done in a OnInit. even if it's a value it could be quite difficult to store. since this must go into gnue_property class, of which type should the corresponding database-column be ? how to store a datetime value and a boolean value or an unlimited string into the same column ? no way, is it ? good question one 'freaky' solution could be to generate a special record in the classes' table itself, say a gnue_id of 'default' holds a record with all default values set but this interferes with the rule to have only anonymous keys well, as you see we have to think about this too :) oh thats like having one default record per table having default values, right? right i don't like this idea very much any places tables have metadata ? because you then have to have some sort of logic which distinguishes between real records and default-records where to place this one ? :)) yeah i guess no good solution. ok, can you suggest another one ? i ask you :) logically speaking the best place would be gnue_property but this won't solve the type-problem and having the type name stored as text? freaky too? i can't follow we know the type it's gnue_property.gnue_type :) ok. gnue_property.gnue_default well is of type gnue_property.gnue_type right, but of which type is that ? blob and then we cast? ;) ok, so for the property address_person.address_meettime it should be of type datetime and for address_person.address_human of type boolean :) this was on reason for having an OnInit () trigger which is python-code and circumvents this problem anyway :) :) because it uses the language-interface it would just fit so nicely as property attribute blob's are very problematic because they're not widely supported by databases, and if they do every database has it's own handling of blobs this was one reason why interbase-db-driver maps 'unlimited strings' into 'string(32000)' maybe appserver has a "gnue_defaults" table with a row for each supported datatype each column is nullable but for each instance there will be one column set then a gnue_property.gnue_defaults could reference a gnue_default row hmm, that won't work you would have one table per datatype change: with a column for each supported datatype or that way so gnue_property.gnue_default is a ref to gnue_defaults. there is the table gnue_defaults ok, so for 'string' and 'string(100)' and 'string(40032)' we would use the 'string' column which is of type string ? or what about numerics? which common type is shared among 'numeric (5.0)' 'numeric(2.1)' 'numeric(17.12)' ? if appserver supports boolean, number and string, the table has 4 coluns: id, boolean_default, number_default, string_default. each nullable, except id. maybe have number plus number_mask where mask can be 5.0 or 2.1 that's the logical point of view, but think db-oriented at this point ok. it doesn't matter wether 5.0 or 2.1 (this information is stored in gnue_property) ok you would have to store 'ALL' numeric default-values into the same pyhsical column in the same table so of which 'technical' type should that column be ... yes we would have to use the most generic (most precise) one and then typecast again how do you do it in xml rpc? how do you put a number into xml tags? 10.0 and 10.5005 same applies to strings that's marshalled in xmlrpc-lib with the information in gnue_property you would know how to read it? but it doesn't matter how xmlrpc handles it can we marshall it? we've to store it :) and put it as string? of which length ? oh yeah not marshalling it just getting a text notation out of it and back :) blob instead of string? no blob is one of the worsest solutions hm ok. if we use blobs, we could just pickle out the native python object and we're finished yeah. * holycow waves hey guys hey holycow SachaS, hows your app coming along? :) hi holycow hey j :) alright i guess. * johannesV_ is stopping SachaS with his comments on modelling ... :) ehe :) at least slowing down a bit haha which SachaS is grateful for! if i would have a bit more time ... was just curiousd :) anything we can take a peek at or? johannesV_ apriory you want to have appserver store everything in the database, right? holycow not ready I guess i guess that makes sense that appserver just uses the backend application... SachaS: which backend application ? backend database sorry. its not that late, is it? :) ? how do you mean 'store everything in the database' ? why dont you just have the text notation? as you have in the .gcd file? "store everything in the database" like not accessing files etc. right johannesV_ if you dump a database you also have all values in a text file. yes, they're typecasted via gnue-common i mean if you use gp_dump for example and dumped by the GParser hierarchy or pg_dump so the typecast is done in pg_dump yes. i suppose so. *** dimas_ has joined #gnuenterprise you mean we should form the gnue_property.gnue_default as a string-type-property and fill it with a string-repr of a given value which get's marshaled and unmarshalled according to gnue_property.gnue_type yes, am i seriously missing something? right ? yeah right. i think this will work for most of the 'flat' types like numbers, (short) strings, dates, bools ok