*** reinhard has joined #gnuenterprise
*** aries_mindworks has joined #gnuenterprise
<aries_mindworks> hi
<reinhard> good morning all
*** btami has joined #gnuenterprise
<ajmitch> hi
*** kilo has joined #gnuenterprise
<kilo> good morning
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<btami> hi
<aries_mindworks> btami, kilo: hi
<aries_mindworks> kilo: did you have time to look inside gnue-invoice?
<kilo> hi
<kilo> well had some time yes but havent succeeded in setting it up
<kilo> will try again soon
<aries_mindworks> ok
*** erkkie has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** kilo has quit IRC
*** kilo has joined #gnuenterprise
*** jcater has quit IRC
*** btami has quit IRC
*** kilo has left #gnuenterprise
*** btami has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** yure_ has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** aries_mindworks has left #gnuenterprise
<jamest> reinhard: gnue datasources now support the master/detail relationships don't they?
<reinhard> they always did
<reinhard> unless I misunderstand what you are asking
<jamest> just a sec and I'll elaborate
<jamest> ok
<jamest> i've started moving my code to business objects here that map to tables
<jamest> here is a complete class
<jamest> class Note(DataAware):
<jamest>   """
<jamest>   Contains a timestamped claim note
<jamest>   """
<jamest>   def __init__(self, connections=None):
<jamest>     DataAware.__init__(self, connections)
<jamest>     self._tableName = 'note'
<jamest>     self._fieldMap  = {
<jamest>       # Table field   : Instance variable
<jamest>       'claim_no'    : 'claim_no',
<jamest>       'userid'      : 'userid',
<jamest>       'date'        : 'timestamp',
<jamest>       'note'        : 'text'
<jamest>       }
<jamest>     self._initializeFieldMap()
<jamest> DataAware is a class that uses gnue datasources to store the info
<reinhard> ok
<jamest> so then in my code I can do
<jamest>     item = ClaimActualItem()
<jamest>     item.load(claim_no = '99-TEST-001', pos_no = 0)
<jamest>     assert item.state == 'PRE-ORDER', \
<jamest>       'Item did not load properly'
<jamest> or
<jamest>     item = ClaimActualItem()
<jamest>     resultList = item.multiLoad(claim_no = '99-TEST-001')
<jamest>     assert len(resultList) == 3, \
<jamest>       'Items did not load properly'
<jamest> it's my hope that over time this will make it far easier for me to port to an appserver type setup
<reinhard> yes that clearly looks very appserverish
<jamest> that's the idea
<reinhard> however I still don't get your question regarding master/detail
<jamest> however where I get into trouble is when an object contains other objects
<jamest> say an invoice that lists invoice items
<jamest> right now I override the base DataAware load and post methods
<jamest> so that in the case of the invoice object it
<jamest> loads via the standard load the invoice data
<jamest> then adds a multiLoad to populate a list of items
<jamest> so by loading the invoice I have all the items associated with the invoice in memory as instances of InvoiceItem
<jamest> so I started looking at how SQLObject handled this and they provide code like
<reinhard> ok
<jamest> items = MultiJoin('ClassName')
<jamest> so i see a few options
<reinhard> this has to happen on your object->sql layer IMHO
<jamest> 1. emulate the sqlobjects behavour in my DataAware
<reinhard> you could of course make it more generic
<jamest> 2. replace my DataAware which uses our DataSources with a object that inherits from our datasources
<jamest> i was thinking that our ResultSet would provide me with the equiv of MultiJoin already
<jamest> if I defined the master/detail relationship as part of the object initialization
<reinhard> no
<jamest> as one time I know that was handles in forms but I thought it moved to common
<jamest> so it's used in appserver, reports, etc, etc
<reinhard> hmmm
<reinhard> I'm not sure if it could be doable somehow
<jamest> my goals are several fold
<jamest> 1. i think i like the my DataAware setup the more I use it and see it as a first step in appserving my apps
<jamest> porting all my stuff to appserver in a single pass would overwhelm me so I taking small steps
<jamest> 2. reading about sqlobjects I believe gnue datasources are more flexible
<jamest> so I think this would be something others might have interest in
<jamest> 3. I could stop overriding every object I have when it contains something else :)
<jamest> but you don't think it doable?
<reinhard> I think you could add that to your DataAware
<reinhard> something like in __init__ have
<reinhard> details = {'items': ('invoice_item', condition_for_the_link)}
<reinhard> then in load and post methods you could generically go through that details list
<jamest> now there's an idea i didn't think about
<jamest> how would appserver expose this?
<jamest> if I your example I'd end up with
<jamest> invoice = instance of Invoice
<jamest> invoice.items = list of instances of InvoiceItem
<reinhard> with appserver you would have to do
<jamest> how close would that be to what appserver would give me on a loaded invoice
<reinhard> invoice_items = find ('invoiceItems', condition = {invoiceHead: myInvoice}, propertylist = [count, price, discount])
<reinhard> and you could also do things like
<reinhard> invoice_items_with_special_status = find ('invoiceItems', condition = {invoiceHead: myInvoice, status: 'foo'}, propertylist = [count, price, discount])
<reinhard> there are no "list properties" in appserver
<reinhard> we have talked about them quite a few times, but never found any reasonable way to design it
<jamest> so you just populate a std python list in the init of the main object?
<reinhard> no
<reinhard> we do that *outside* the object definition
<reinhard> in the application
<jamest> or you store them completely separate
<reinhard> yes
<jamest> so you can't load invoice and get all the invoice items
<reinhard> not other than with a line like above
<reinhard> the proble is if we supported something like myInvoice.items
<reinhard> we couldn't define what sort order the list should have
<reinhard> what fields to load from the db (gets important if every invoice item contains a blob with the picture of the item...)
<reinhard> and all that stuff
<jamest> makes sense
<jamest> fwiw: i think sql object makes all such references Generators that load data upon demand
<reinhard> yes, this is also a solution
<jamest> it also by default performs an update each time a object property value is changed
* jamest shudders
<reinhard> ah oh
<reinhard> so you mean
<jamest> foo = MyThing()
<reinhard> every access to a single property of the object issues its own sql statement?
<jamest> foo.x = 1
<jamest> <sql update>
<jamest> foo.y = 2
<jamest> <sql update>
<reinhard> foo.z = foo.a + foo.b
<reinhard> <sql select>
<reinhard> <sql select>
<reinhard> <sql update>
<reinhard> ?
<jamest> not in that case
<jamest> it caches in memory
<jamest> so I think they do
<reinhard> but if foo.a is accessed for the first time?
<jamest> foo = Object() (with items being a MUltiJoin)
<jamest> for item in foo.items[:10]
<jamest>   <sql select limit 10>
<jamest> then after that I do
<jamest> foo.items[2]
<jamest> <uses previous value>
<jamest> foo.items[15]
<jamest> <I *think* select limit 15>
<reinhard> but what fields does it include in the select?
<reinhard> all?
<jamest> yes
<jamest> in sqlobject it looks like you do
<jamest> def Foo:
<jamest>   then in the __init__
<jamest>   add text column bar
<jamest>   add int column baby
<jamest>   add text column oh_yeah length = 10
<jamest> then a Foo.createTable()
<jamest> foo
<jamest>   bar text
<jamest>   baby  integer
<jamest>   oh_yeah varchar(10)
<reinhard> ok
<jamest> but I didn't see anything that limited the load of fields
<jamest> and complex joins are impossible
<reinhard> and if I need the oh_yeah field only in 1% of the cases
* jamest read thru the docs only didn't setup a test install
<reinhard> it would still be requested anytime I access foo?
<reinhard> ok
<jamest> i believe so
<jamest> this is why I think our datasources are more flexible
<reinhard> nice
<reinhard> that pretty much stops you from using blobs ;-)
<jamest> as even in my DataAware i can do
<jamest> load(field = 1, field2= 3)
<jamest> or
<jamest> load (conditions=<Dict or Std GConditions tree>)
<jamest> i think think it'd be fairly trivial to add
<jamest> load (condiitons, excludeFIelds = ())
<reinhard> yeah
<reinhard> or includeFields
<reinhard> :)
<jamest> right
<jamest> so I really see our datasources as better
<reinhard> I agree entirely
<jamest> it sounds like I need to not think about inheriting from our datasources directly
<jamest> and instead extend my DataAware to be more flexible
<reinhard> I would think so
<reinhard> although I haven't thought through it in depth
<reinhard> datasources never wanted to be an object-sql mapper in the first place
<reinhard> (AFAICT)
<jamest> no, it never was
<jamest> i'm just trying to make the jump to business objects from a system not designed for business objects less painful
<jcater> and I'm just watching from afar, so I can "borrow" jamest's code when he's got the bugs worked out
<jamest> i have to go pick up my wife but I'd be curious if this stuff would be useful in common at all
<jamest> another issue involves the connection manager
<reinhard> might be
<jamest> jcater: i completely forgot I do have a singlton setup for that, i went in to add it and it was already there :)
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
*** btami has quit IRC
*** btami has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** btami has quit IRC
*** johannesV has quit IRC
<jamest> reinhard: you guys haven't happened to setup a set of test tables have you?
<jamest> with some test data
<reinhard> we usually use zipcode for testing (2-tier)
<jamest> would there be an advantage to having maybe 2 tables
<jamest> testTableA and testTableB
<jamest> with an 1:N relationship
<reinhard> zipcode is 2 tables with a 1:N relationship
<jamest> with every field type commonly in use
<reinhard> ah
<reinhard> we've done that "every field type" thingy in the appserver sample
<reinhard> I think kilo has ported this sample to 2-tier
<jamest> that might work
<reinhard> should be findable in gnue-forms samples IIRC
<reinhard> however that one doesn't have master/detail
<jamest> i'm just getting ready to try extend my object mapper and so started writing unit tests for it
<jamest> and thought maybe this would be handy for gnue unit tests as well
<jamest> are you talking about gnue-samples/testcases/appserver ?
<jamest> the gsd in there?
<reinhard> I'm not sure, I've never used it myself
<reinhard> but it sounds like that, yes
<reinhard> well, it actually *has* a 1:N relationship with country : person
<jamest> reinhard: looks like a gsd file doesn't exist which I assume would be avail if kilo ported it
<jamest> iirc appserver used gcd files
*** dyfet has joined #gnuenterprise
<jamest> is gnue-schema still used?
<jamest> gsscvs?
<reinhard> yes
<jamest> i'm trying to get it to dump a schema from a gsd file I just made
<jamest> --mode=data errors out
<jamest> and it's not adding the data to the output file
<jamest> it's also assuming a username of gnue and failing on login instead of defaulting to the connection managers login prompts if a username/password isn't passed in
<jamest> is that how it should work?
<reinhard> are you running on a connection or into a file?
<jamest> trying into a file, running to a connection tracebacks
<reinhard> what did you try?
<reinhard> (can you give me the command line?)
<jamest> gsscvs -f -o out.sql -c devel -u jamest -p *snip* testTables.gsd
<jamest> if I lose the -u and -p then it complains about pam failure for user gnue
<jamest> if I lose the -p then pam failure for user jamest
<jamest> if I lose the -f and -o ...........odd.........it now doesn't give the None type traceback
<reinhard> weird
<reinhard> it actually shouldn't try to log in at all if you do -f
<jamest> with just gsscvs -c devel -f -o out.sql testTables.sql
<jamest> it gives a PAM authentication failed for user "gnue"
<reinhard> not that it would *completely* explain the symptom
<reinhard> but could you maybe try in datasources/readgsd.py
<reinhard> lines 237 and 238
<reinhard> replace 'username' with '_username' and 'password' with '_password'?
<reinhard> err no
<reinhard> line 246 and 247
<reinhard> but I keep getting confused with the 'username' vs. '_username' parameter
<jamest> same
<reinhard> I mean it should accept username and password on command line then
<jamest> oh that worked
<jamest> if you left -p off it'd fail
<reinhard> something is hosed here
<reinhard>       if (loginData.has_key ('username')):
<reinhard>         loginData ['_username'] = loginData ['username']
<reinhard>         del loginData ['username']
<reinhard>       if (loginData.has_key ('password')):
<reinhard>         loginData ['_password'] = loginData ['password']
<reinhard>         del loginData ['password']
<reinhard> that actually does exactly this username -> _username
<reinhard> care to create an issue in our tracker? :-)
<reinhard> must run off for a bit but bbl
*** yure has quit IRC
*** kilo has joined #gnuenterprise
<reinhard> back
*** klasstek has joined #gnuenterprise
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** klasstek has quit IRC
*** klasstek has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** erkkie has quit IRC
*** klasstek has quit IRC
*** klasstek has joined #gnuenterprise
*** dyfet has quit IRC
<reinhard> good night all
*** reinhard has quit IRC
*** kilo has left #gnuenterprise
*** derek has quit IRC
*** klasstek has quit IRC
*** jcater has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** jamest has quit IRC
*** sjc has quit IRC
*** jcater has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** jcater has left #gnuenterprise
*** derek has joined #gnuenterprise
*** sacha__ has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** jamest has quit IRC
*** jcater has left #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** bigbrother` has joined #gnuenterprise
*** bigbrother has quit IRC
*** Poincare has quit IRC
*** nickr has quit IRC
*** nickr has joined #gnuenterprise
*** Poincare has joined #gnuenterprise