*** reinhard has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<reinhard> good morning all
<kilo> good morning
<ajmitch> hi
*** johannesV has joined #gnuenterprise
<johannesV> good morning
*** btami has joined #gnuenterprise
<btami> good morning
*** yure has joined #gnuenterprise
*** bigbrother has joined #gnuenterprise
*** bigbrother` has joined #gnuenterprise
*** sacha has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** btami has quit IRC
*** yure has quit IRC
*** jamest has joined #gnuenterprise
<jamest> reinhard: did you happen to look at the sample gsd files I put into gnue-samples?
<reinhard> no, but I think johannesV did
<reinhard> let me look quickly
<jamest> i'm curious to know if something like this could be expanded and all samples the applications setup to use this structure
<jamest> along with unit tests
<jamest> in gnue-contrib/objectWrapper/tests/objects I setup classes that wrapper those tables and setup unit tests that use the know info loaded into the tables to verify my code
<jamest> i could see the same done in all gnue-apps
<reinhard> you mean write unit tests that use this thest data?
<reinhard> we already did that in appserver, actually
<reinhard> gnue-appserver/tests/data.py
<jamest> i thought the appserver test structure was just country address stuff?
<jamest> I'm seeing starship personnel
<jamest> :)
<reinhard> that's the address :)
<jamest> where is the defintions for that stuff?
<reinhard> address is including name, birthday etc
<reinhard> gnue-appserver/samples/sample.gsd
<jamest> i swore that was  just data
<reinhard> eh
<reinhard> yes it is
<reinhard> you mean the schema?
<jamest> yes
<reinhard> it's sample.gcd
<jamest> i'd like to have a master schema testkit like we talked about in gnue-samples
<jamest> that all apps/samples/tests can use
<jamest> if you're ok with that
<reinhard> FWIW, it would be no biggie (IMHO) to move our test data to a different schema
<reinhard> and I agree that we should use a common testkit
<jamest> the test schema i started with is a simplified version of stuff running here
<jamest> it's invoices in the sample but orders here
<reinhard> AFAICT, the sample is ok
<jamest> it has a 1:N invoice - invoiceItem relationship
<johannesV> but we still need to define appserver's schema using a gcd (as this populates the class repository)
<reinhard> we should just take care that it contains all possible field types
<jamest> i'm still missing some types in that sample
<jamest> like booleans
<reinhard> date, time, datetime, boolean, test, number with and without fractions
<reinhard> so we'd want to add some fields
<jamest> one thing in that sample that was a gotcha for objectWrapper
<jamest> if you look at objectWrapper/tests/objects/invoiceAddress.py
<reinhard> also, johannesV has introduced a fishhook for testing purposes
<jamest> in that Join defined in there you'll see a prePost
<reinhard> should I?
<jamest> where the address has commit prior to the invoiceObject
<jamest> that was an odd case I wanted in the schema
<jamest> what's a fishhook?
<reinhard> a table referencing itself
<reinhard> like item -> replacement item
<jamest> that's a good one too
<reinhard> or employee -> his boss
*** derek has quit IRC
<reinhard> address -> invoice address
<jamest> also
<jamest> if you could spare a minute to look at objectWrapper/tests/objects/invoice.py
<jamest> down at the bottom I have a section called Accessors
<reinhard> yes, I see it
<jamest> where it maps class fields to converters
<jamest> so that setDecimal converts FIxedPoint, strings, floats, ints to Decimal
<jamest> and setDatetime does something similar
<jamest> i find myself doing that all the time
<jamest> but I didn't know if it'd be of use in common at all
<jamest> in my case those lines at the bottom take care of all conversions for me in my code and I no longer worry about what the db provides
<jamest> something else not shown in invoice.py is a coalesce() function
<jamest> which works exactly like postgresql's coalesce
<jamest> so instead of doing
<jamest> if foo is None:
<jamest>   bar = {}
<jamest> else:
<jamest>   bar = foo
<jamest> i just do
<jamest> bar = coalexce(foo, {})
<jamest> or coalesce(x,y,z)
<jamest> again, i'm using this a lot
<jamest> it's a minor thing but handy
* jamest is trying to figure out if any of this would be of use to others and if so where I'd put them in common
<jamest> which reminds me
<reinhard> FWIW, appserver does this setDecimal etc stuff internally. not sure how it would be used in common outside the object wrapper
<reinhard> bar = coalexce (foo, {}) seems to be the same as
<reinhard> bar = foo or {}
<reinhard> I don't understand what coalesce (x, y, z) would do
<jamest> hmmmmm
<jamest> picks the first non null value
<reinhard> ah
<reinhard> bar = x or y or z
<reinhard> :)
*** kilo has left #gnuenterprise
<jamest> lol
<jamest> i hadn't thought about just using or
<jamest> readgsd.py made me think of my coalesce
<jamest> as it does the if foo is not None stuff
<reinhard> sometimes the if foo is not None is better readable/understandable
<reinhard> sometimes I think foo = a or b is enough
<johannesV> reinhard, watch out ! if foo is 0 doing something like bar = foo or {} ... would set bar to {} instead of 0
<jamest> that's the same issue as the x and x or y trick to mimic the C ?: operator
<johannesV> so if one has to check the Null-state of a value doing a "poor man's ternary operation" is not the same
<jamest> oh, a postgresql 8.1 gotcha
<jamest> postgresql 8.1 no longer created oids by default on tables
<reinhard> johannesV: yes, right
<jamest> but we expect them unless we specifically specify the PK fields to use
<jamest> but if we specify the PK fields then our datasources always add that field value in as NULL
<jamest> which can blow up the insert as insert into invoice (invoice_no) values (Null) will ignore the fields default setting and issue an error
<jamest> you can see the issue if you run the objectWrapper unit tests after uncommenting out the post after "TODO: The old " in the joins.py file
<reinhard> hmmm.....
<jamest> you can force postgresql 8.1 to create the oid field if you create the table with "WITH OIDS" option
<reinhard> Base/RecordSet.py line 197
<reinhard>       # 3. Set the primary key fields to dirty, so they will be included in the
<reinhard>       #    insert statement in any case.
<reinhard> why did I do this?
<reinhard> I think it was related to the appserver backend
<jamest> i can't think of a reason forms or any of my apps would require it
<jamest> but I think the main issue is our dependence on OIDs in pgsql
<jamest> i'm no where near up to speed on gnue-common but at one time we had the oid field hardcoded in as the pk
<jamest> and it didn't try to figure out the pk, you could only override
<reinhard> the oids are good and necessary
<jamest> they are discouraged in postgresql 8.1
<reinhard> without oid, you can't use db triggers to generate a primary key
<jamest> well, 8.0
<reinhard> discouraged?
<jamest> but 8.1 flipped them off by default
<jamest> yes
<reinhard> so if you have a table where the pk is assigned from a serial
<jamest> no new table created in 8.1 will have them unless you specifically tell it to create them
<reinhard> how would you find out which serial you got on an insert?
<johannesV> i'm pretty sure there's a function to retrieve that value
<jamest> i honestly don't know, i'm just bringing to light a nasty that bit me when I moved to 8.1 recently
<jamest> my _primaryKeys="" hack in objectWrapper got me around it in most cases
<johannesV> (sqlite3 for instance, provides this number via cursor object: cursor.lastrowid)
<jamest> but not in cases where i have the serial populated by a default nextval('seq')
<jamest> as then the insert of the NULL by common blows it up
<jamest> hmmmm
<jamest> s/hmmmmm//
*** jcater_ is now known as jcater
<jamest> so now that I shared the 8.1 love
<jamest> how should I proceed on the gnue-samples?
<jamest> do I move the gcd and gsd sample files into appserver then make the schema's sorta match?
<jamest> well, make them match acutally
<reinhard> I'd say just go on with the 2 tier sample
<reinhard> and we will port it to appserver
<reinhard> if that is ok for you
<jamest> sure, but I'm ok with working with the appserver defs too if you guys can put up with lots of questoins
<jcater> what is the appserver test schema?
<jamest> its a schema used for testing
<jamest> testing is what you do with code before you give it to users
<jamest> i'm sure that's what threw you
<reinhard> jcater: currently we use a simple address management with 2 tables, but we will change to what jamest is now building in gnue-samples
<jcater> jamest: what is your schema?
<jamest> it's a simple invoice atm
<jamest> with items and address tracking
<jcater> okay
*** chillywilly has joined #gnuenterprise
<jamest> if you have something better I'm open to change
<jamest> i just needed something more than my test_detail and test_master tables at work
<jcater> not necessarily
<jamest> and wanted it for gnue
<jcater> I'd just like to use something common for some of my stuff too
<jamest> i think we're talking about revamping all the various samples in gnue
<jamest> as so many are broken
<jamest> and make a single, consistant sample system
<jcater> yeah
<jamest> nothing complex
<jamest> that's what I started in gnue-samples
<jamest> reinhard: do you agree with that?
*** sacha has quit IRC
<jamest> jcater: we'll end up with two sets of schema (two-tier and appserver)
<jcater> I had someone create an employee/project assignment/timeclock schema inhouse for sample stuff too
<jcater> but I'd like to be using one consistent w/gnuew
<jcater> gnue
<jamest> where the appserver one has gcd's to create it, and gsd to populate it
<jamest> well, i think we could probably put that in gnue-sample as well if everyone is ok with it
<jamest> as I see this populating the 'gnue' database with a very simple but sorta complete system
<jcater> I wasn't pushing for mine, btw
<jcater> in any way
<jamest> i'm looking for samples :)
<jamest> as I want I've done is dumb down the ones from work
<jcater> we have 300 employees
<jcater> with full addresses
<jamest> s/want/what
<jamest> as no way to I care to have a demo which consists of the horror which is the simplified sales tax plan here in the US
<jamest> those are demo employees?
<jcater> yeah
<jamest> i think it'd be nice to have those samples, especially due to the size of the dataset
<jamest> reinhard: would that be OK to add to samples?
* jcater would rather see one sample set though... I'm cool with invoices
<jcater> I was just trying to stay in the loop so I can use them too :)
<reinhard> I agree that we should have *one* sample set
<reinhard> and even more, I think it should not be too complex
<reinhard> and I am not sure if we really need 300 records in our sample database
<reinhard> as 300 is too little anyway to do performance tests
<jcater> fwiw, this sample set was mainly used for reporting tests
<jcater> which explains the size
<jcater> but I agree
<reinhard> and OTOH it's too much as that you could easily predict what should come out of a specific operation
<jamest> so what would be a good size
<jamest> as in the case of invoices i think 1 is a tad small :)
<reinhard> in the appserver sample I think we had 5 records
<reinhard> I think something between 5 and 10 might be enough
<reinhard> but I won't hold you back
<reinhard> :-)
<jamest> 5 to 10 seems fine to me
<jamest> as I'd like to have a few to throw different combos at stuff
<jamest> my invoice compiler unit tests here run thru all the invoices created for the month
<jcater> well, imho, we need a schema that has a few core tables that might be 5-10, but has some sort of detail tables that can be larger
<jcater> as 5-10 is a great sample test size for stuff like appserver, forms, etc
<jamest> and it hasn't been uncommon that the 304th invoice blows up due to some minor thing
<jcater> but not for reporting or other aggregate-type things
<jcater> which for invoicing, could be some sort of "transaction history" table if nothing else
<jamest> jcater: can you convert your sample stuff to gsd then, or give to me and I will
<reinhard> good idea with transaction history
<jcater> reinhard: do you see what I'm getting at?
<reinhard> would also fit the reporting area
<reinhard> yes
<reinhard> sure
<jcater> imho, the perfect schema is one that allows you to access either a small or a large data set
<jcater> depending on your needs
<reinhard> agree
<jamest> i need less users
<jamest> and more time
*** klasstek has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
<johannesV_> jamest, i've just commited a new version of postgres' Behavior.py
<johannesV_> now you should be able to do something like: gnue-schema -c newone -d -u dbadmin -p <snip> --owner=gnue --ownerpassword=<snip> gnue.gsd
<jamest> cool, thanks
<johannesV_> that should connect to the server using dbadmin/<snip1>, add (if necessary) a user "gnue/<snip2>"
<johannesV_> and finally creates the db as given in "newone" connection
<johannesV_> successive connections to that db might follow as user gnue/<snip2> of course
<johannesV_> bbl
<jamest> so if we're moving to just the invoicing sample
<jamest> what do we do with all the samples in, say gnue-forms, that access the db
<jamest> pitch them?
<reinhard> finally yes
<reinhard> I'd guess > 50 % of them are broken anyway
<jamest> ok
<jamest> we've got stuff all over the place
<jamest> and I can (hopefully) put a little time each day into cleanup
<jamest> should we keep any samples in the individual tool dirs?
<jamest> like helloworld for forms
<jamest> or move all of it to samples
<jamest> say a appserver, two-tier, and unbound dir.....maybe
<reinhard> I wouldn't mind ditching helloworld.gfd
<reinhard> (but I also wouldn't mind keeping it)
<jamest> but where to put?
<jamest> i can see advantage in having all the gnue-samples
<jamest> in that it'd be simple to compare the 2tier to the appserver samples
<jamest> since they are going to do the same thing
<jamest> and I'd imagine in some cases the forms will match
<reinhard> I don't really care much about the helloworld.gfd
<reinhard> you can put it 2-tier if you want
<reinhard> I will easily port it to appserver ;-)
<jamest> i mean in general though
<jamest> where will all samples go?
<reinhard> I think we might still keep a per-tool samples directory
<reinhard> thinking about it, there are some things in appserver/samples that we might well keep besides the big general sample
<jamest> no way to port them over, or just basic functionality samples?
<jamest> i could see common having lots of non db samples
<reinhard> things that we do not *want* in gnue-samples
<reinhard> like special broken testcases to test exceptions
<reinhard> or benchmarks
<jamest> ok
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
*** krizz has joined #gnuenterprise
<jamest> btw, i saw the new forms splash this weekend
<jamest> who made that?
<johannesV> it was me
<johannesV> :)
<johannesV> do you like it ?
*** reinhard has left #gnuenterprise
<jamest> it's better than the old one by far :)
<johannesV> thanks ... :)
*** reinhard has joined #gnuenterprise
<johannesV> i had some spare time left and, well, i needed to do some creative work ...
<reinhard> http://www.rahoi.com/2006/03/may-i-take-your-order.php
<johannesV> *lol*
<jamest> :)
*** johannesV has quit IRC
*** krizz has quit IRC
*** kilo has joined #gnuenterprise
*** reinhard has quit IRC
*** jamest has left #gnuenterprise
*** sjc has joined #gnuenterprise
*** klasstek has quit IRC
*** kilo has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
<derek> jcater: you there?
<jcater> depends on who's asking
<SachaS> derek there is the ruby meeting starting in 10 minutes ;)
<derek> im still at work
<derek> chances of me making 1 hour away in 10 minutes when i have 30 minutes of work or more left is slim to none :(
*** jcater has quit IRC
*** SachaS is now known as SachaAway
*** derek has quit IRC
*** jcater has joined #gnuenterprise
*** sjc has quit IRC
*** derek has joined #gnuenterprise