*** derek has joined #gnuenterprise
*** aries_mindworks has joined #gnuenterprise
<aries_mindworks> hi
*** bigbrother_ has quit IRC
*** bigbrother has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<derek> doh...
<derek> i think that is my signal that it's past my bedtime :)
<johannesV> :)
<aries_mindworks> :)
<aries_mindworks> hi all
<johannesV> hi aries_mindworks
<aries_mindworks> now the curses driver seems to me working, but if when I tried in gnue-invoice to make a new invoice, it said: <gnue.forms.GFObjects.GFImage.GFImage instance (imgURL) at -1215188724>
<johannesV> hm, curses does not support images :)
<johannesV> maybe we should think about ascii-arts ....
<aries_mindworks> ok, It won't show me the image, but it would nice if I can enter data
<johannesV> *lol*
<aries_mindworks> johannesV: :)
<johannesV> so, does the form stop there or what happens ?
<aries_mindworks> it should strip the unsupported features
<aries_mindworks> johannesV: It brings me back to tha "main" page
<aries_mindworks> johannesV: where I can see the grid, I cannot enter new invoice
<johannesV> hm, i don't know gnue-invoice very well
<johannesV> so maybe kilo could give some help there ...
*** reinhard has joined #gnuenterprise
<reinhard> hi all
<aries_mindworks> reinhard: hi
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** btami has joined #gnuenterprise
*** yure has joined #gnuenterprise
<aries_mindworks> I've try to implement a calculated property it should select the last value of a previous records given value
<aries_mindworks> eg. customer's balance (number(5)) where -50$ on the last time. I'd like to get this value. how can I do this?
<reinhard> I don't understand
<reinhard> you mean previous as in "first record, next record..."
<reinhard> or previous as in yesterday?
<aries_mindworks> the previous record of that customer
<reinhard> a customer has more than one record?
<aries_mindworks> like this: select balance from customer where customer.id=500
<reinhard> sorry I still don't understand
<reinhard> is there more than one class involved?
<reinhard> and how are they related?
*** kilo has joined #gnuenterprise
*** erkkie has joined #gnuenterprise
<aries_mindworks> reinhard: there's a <property name="netezo"    type="PERSON_Person"         comment="Internetezo" /> property
<aries_mindworks> reinhard: I've sent you a mail
<reinhard> haven't got any mail from you
<aries_mindworks> reinhard: I've sent it to reinhard@gnue.org
<aries_mindworks> 2006-02-01 11:53:54 1F4FcU-000HjY-1n == reinhard@gnue.org R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<reinhard@gnue.org>: host mail.gnuenterprise.org [70.158.36.94]: 450 <reinhard@gnue.org>: Recipient address
<aries_mindworks> rejected: Greylisted for 300 seconds (see http://isg.ee.ethz.ch/tools/postgrey/help/gnue.org.html)
<aries_mindworks> erm
<reinhard> aries_mindworks: please avoid writing email addresses in this channel
<reinhard> this channel is logged on a web page indexed with google
<reinhard> please try reinhard (dot) mueller (at) bytewise.at
<reinhard> off to lunch
<aries_mindworks> reinhard: ok, sorry
<reinhard> erh
<reinhard> just got your mail :)
<reinhard> will look at it after lunch
<aries_mindworks> reinhard: thanks
*** kilo has left #gnuenterprise
<reinhard> ok
<reinhard> trying to understand
<reinhard> shouldpay is what the customer should pay for *this* order, right?
<reinhard> and balance is what the customer should pay for *all* of his orders?
<reinhard> including this one?
<aries_mindworks> yes
<aries_mindworks> you're right
<reinhard> so you would do something like
<reinhard> <property name="balance"    type="number(6)"              comment="Egyenleg" >
<reinhard>   orders = session.find ('orders', conditions = {'netezo': self.netezo}, propertylist = ['shouldpay'])
<reinhard>   for o in orders:
<reinhard>     sum += o.shouldpay
<reinhard>   return sum
<reinhard> </property>
<reinhard> and of course you would initialize sum to 0 before the "for" line
<aries_mindworks> reinhard: thanks, i'll try it
<erkkie> reinhard: I was thinking about doing a in-stock counter for items in a way similar to that.. I would have to count all shipping orders & all sales orders & the sum would be the current "in-stock" counter.. but I worried how would this scale with large amounts of orders
<reinhard> erkkie: I can predict that quite well
<reinhard> it would scale *horribly*
<reinhard> as it would result in a SQL query for each time you access the in-stock counter
<erkkie> reinhard: yeah, I figured that:)
<reinhard> I would rather have on-validate and on-delete triggers that update a stored field
<erkkie> yeah, that was the way I did the stuff eventually
<reinhard> and a method to recalculate in case it gets out of sync ever
<erkkie> but that has concurrency problems, but fortunately, my stuff is single user.. and yes, I figured, that I'd need to to consistency checks every now and then
<erkkie> but I haven't implemented the checks yet
<erkkie> was thinking about implementing a custom transaction queue of some sort, but haven't had the time to get around figuring the exact order of the validation triggers
<erkkie> wasn't sure if it would be easily done with .gcd files only
<reinhard> calculated field *might* be worth discussing for stuff like "reserved stock" (like in accepted but not yet fulfilled orders)
*** btami has quit IRC
<reinhard> concurrency problems should actually be solved by the database
<reinhard> all OnValidate and OnDelete triggers run within the same atomic transaction that also stores the actual change
<erkkie> I read the postgresql locking docs, somehow I got the picture that in some cases consistency isn't guaranteed, unless there's a locking statement in the sql query... I haven't checked the queries that appserver produces, so I could be just trolling here:p
<erkkie> reinhard: I just looked at the sql queries that appserver makes.. it set the transaction isolation level to serializable.. I don't fully understand the different isolation levels yet, but I trust that takes sure of the concurrency stuff
<reinhard> erkkie: honestly I wouldn't *bet* on it
<reinhard> but at some point appserver will support active locking
<erkkie> reinhard: yeah, you must be sick of repeating that to me:)
*** yure_ has joined #gnuenterprise
*** aries_mindworks has quit IRC
*** jamest has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** sacha__ has quit IRC
*** sacha__ has joined #gnuenterprise
*** sacha__ has quit IRC
*** btami has quit IRC
<jamest> hmmm
<jamest> i thought that datasources would cast data to match the DB field
<jamest> so that a boolean field in the table would be a boolean data type
<reinhard> no
<reinhard> never did
<reinhard> and in fact I think introspection is not reliable enough to do *that*
<jamest> ok
<reinhard> for example, some backends simply have not boolean but use a int
<jamest> wait, we did that in the display handlers in forms
<jamest> didn't we
<reinhard> right
*** derek has quit IRC
*** klasstek has joined #gnuenterprise
<jamest> reinhard: you here?
<reinhard> yes
<jamest> whoops.  still here?
<reinhard> in and out
<jamest> same here
<jamest> ok
<jamest> i was hoping you could give some feedback on that object wrapper
<jamest> right now in python i can do
<jamest> class Order(ObjectWrapper):
<jamest>   """
<jamest>   Contains basic information about a single pickticket
<jamest>   """
<jamest>   _tableName = 'orders'
<jamest>   _properties = (Field('order_id',      typecheck=int),
<jamest>                  Field('created'),
<jamest>                 Join('payments', className=OrderPayment,
<jamest>                        masterLink='order_id', detailLink='order_id'),
<jamest> )
<jamest> or things like
<jamest> Join('actualItems', className=OrderItem,
<jamest>                        masterLink ='order_id', detailLink='order_id',
<jamest>                        extraConditions = { 'item_type' : 'EQUIV',
<jamest>                                          }
<jamest>                      )
<jamest> which sets up objects with the attributes 'order_id', 'created', and a list named actualItems
<jamest> Fields can also map from table field name to different instance name and you can specify an optional typecheck=float,Decimal,int, basestring, etc,etc
<jamest> which can then test fields that you setup getters and setters on
<jamest> so a complete object mapping would read something like
<jamest> class Master(ObjectWrapper):
<jamest>   """
<jamest>   Contains basic information about a single pickticket
<jamest>   """
<jamest>   _tableName = 'test_master_table'
<jamest>   _properties = ( Field('master_id',     typecheck=int),
<jamest>                   Field('decimal_field', typecheck=float),
<jamest>                   Field('txt_field',     typecheck=basestring),
<jamest>                   Field('bool_field'), # ,    typecheck=bool),
<jamest>                   Join('details', className=Detail,
<jamest>                        masterLink='master_id', detailLink='detail_id'),
<jamest>                 )
<jamest> then you can access it like
<jamest>     order = Master()
<jamest>     order.load(master_id = 1)
<jamest>     assert order.txt_field == 'Master 1', \
<jamest>       'Object did not load properly'
<jamest>     assert order.bool_field == True, \
<jamest>       'Object did not load properly'
<jamest>     assert len(order.details) == 5, \
<jamest>       'Object items did not load properly'
<jamest> so that's the basic functionality with load, multiload, and post methods
<jamest> I know yesterday we talked about adding limits on the fields pulled in a load
<jamest> and I'm curious if this is still close to appserver's object setup
<reinhard> yes it is
<reinhard> except that in appserver you can't predefine a list property
<reinhard> FWIW, I don't want to explicitly pour salt into anybody's wounds here, but
<reinhard> I just tried a 12 year old trousers for carneval and it still fits ;-)
<jamest> lol
<jamest> reinhard: do you have any suggestions on making this more appserverish?
<jamest> also if I add a limitFields option to both loads and joins
<jamest> so object.load(master_id =1, limitFields=['instanceFieldName','instanceFieldName2',etc])
<jamest> and the same list as part of a join
<jamest> Join('details', className=Detail,masterLink='master_id', detailLink='detail_id', limitFields=['instanceFieldName','instanceFieldName2',etc])
<jamest> what issues do you recall that would have remained that prevented you from doing imbedded lists in appserver
<jamest> also, i'm thinking on a Join of having another arg type='single' or type='list'
<jamest> so that if single then the details attribute would be an instance instead of a list
<jamest> lunch, bbi1h
<reinhard> jamest: issues were field selection and sorting
<reinhard> the main issue with field selection is that you probably can't predefine it
<reinhard> because in one case you need item numbers for order items, in other case you need price, in other case you need both
<reinhard> bbl too
*** johannesV__ has joined #gnuenterprise
*** johannesV_ has quit IRC
<reinhard> back
<jamest> reinhard: you wouldn't pass the fields in as part of the master object load?
<reinhard> hmmm
<reinhard> that could make sense
<reinhard> actually that sounds like a really good idea
<jamest> load (....., childFields = {'details': ['a','b','c'}, 'partList' : ['z']}
<reinhard> something like
<reinhard> yes
<reinhard> or even (more appserverish)
<reinhard> propertylist = ['field1', 'field2', 'list.fielda', 'list.fieldb']
<reinhard> I seriously start to reconsider list properties
<jamest> i'd think ordering would work the same way
<reinhard> well
<reinhard> ordering could possibly be predefined for the list property
<jamest> where order could be either a GConditional tree, or a string
<jamest> i'm not following what you mean by predefined for the list property
*** dimas_ has quit IRC
<reinhard> jamest: there are things you define when you define the object
<reinhard> and other things you only give when you use the object later, like as parameter in load() or such
<reinhard> I understood that for example the link between the tables is "predefined" (means declared in the object definition)
<jamest> ok, but what if I have an order and I load the orders for a report where they list items in the order entered
<jamest> then I load the same order for a report but items are sorted by value
<jamest> Order 1
<jamest>   Pos 1 item  $50
<jamest>   Pos 2 item $10
<jamest> vs
<jamest> Order 1
<jamest>   Pos 2 item $10
<jamest>   Pos 1 item $50
<jamest> i could see changing the sort order of detail lists as useful in cases like that
<jamest> as i have several web reports where the user can change the sort order of the results on the fly
*** sjc has joined #gnuenterprise
<reinhard> In that case you would do 2 separate datasources
<reinhard> (maybe)
<reinhard> you can always do a separate load() for the details as you need it
<reinhard> those list properties are only a kind of shortcut for that load() per master record
<reinhard> at least that is my understanding
*** johannesV__ has quit IRC
<jamest> hmmm
<jamest> ok
<reinhard> not saying that this is the right approach
<reinhard> just it's the approach I had in mind when last thinking about it
<reinhard> :)
<jamest> should I put this object wrapper into common somewhere
<jamest> i see it as a go between for me moving from relational stuff to something more appserverish
<jamest> i also see it as similar to sql objects
<jamest> but it's not appserver
<jamest> obviously :)
* jamest is trying to figure out if he should just leave in his svn tree or if it has value outside this company
<reinhard> hard for me to tell
<reinhard> I won't use it, however I see it might be of use for others
<reinhard> you could also consider parking it in gnue-contrib for now
<reinhard> and when we see people adapting it then make it "official"
<jamest> good idea
<reinhard> s/adapting/adopting/
<jamest> where would be the best place to find appserver api usage
<jamest> i really want this thing to get me closer to porting to appserver
<jamest> but with appserver being an all or nothing option
<jamest> i can't begin to jump from my old relational way of doing things to appserver company wide
<jamest> but if I can make object wrapper API very, very close to appserver then (I hope) the jump would be much, much easier
*** derek has joined #gnuenterprise
<reinhard> jamest: the appserver devguide should help
<reinhard> as to all or nothing
<reinhard> you might be interested in the latest wishlist items in our tracker ;-)
<reinhard> (I really see this as a problem, too)
<reinhard> appserver devguide should be downloadable from our web page
<reinhard> must run now
<reinhard> cu
*** reinhard has quit IRC
*** kilo has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** klasstek has quit IRC
*** yure has quit IRC
*** derek has quit IRC
*** kilo has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** erkkie has quit IRC
*** sjc has quit IRC
*** jcater has left #gnuenterprise
*** jcater has joined #gnuenterprise
*** jamest has quit IRC
*** dimas has joined #gnuenterprise
*** jcater has left #gnuenterprise