[web2py] Re: dal aggregation sum fields None

2011-10-23 Thread Massimo Di Pierro
lines[cash_price]=lines(cash_price) or 0 

On Oct 22, 7:50 am, Anthony abasta...@gmail.com wrote:
 On Saturday, October 22, 2011 7:47:08 AM UTC-4, apple wrote:

  I am summing some data using the DAL:
        cash_price = db.orderline.cash_price.sum()
        lines = db(db.orderline.order_ == id).select(cash_price).first()

  However if there are no lines then lines[cash_price] is None. So I
  added:
         lines[cash_price]=lines[cash_price] or 0

 But this does not work either. You have to do:

         lines[cash_price]=lines._extra[cash_price] or 0

  This is OK as it works. But wouldn't it be better if the sum were 0
  in the first place? Or if there is some logical reason for it to
  None then one should to be able to say:
         lines[cash_price]=lines[cash_price] or 0

 I don't think you necessarily want it to default to 0 whenever no records
 are found, as you might want to distinguish between that case (None) and
 when there are records but the sum is truly 0. However, it would be nice if
 the assignment above worked without needing to refer to _extra.

 Anthony


[web2py] Re: dal aggregation sum fields None

2011-10-23 Thread Anthony
On Sunday, October 23, 2011 11:49:31 AM UTC-4, Massimo Di Pierro wrote:

 lines[cash_price]=lines(cash_price) or 0  


I don't think that will solve the problem. That will add a new 
'SUM(orderline.cash_price)' key to lines rather than updating 
lines._extra['SUM(orderline.cash_price)']. However, when you subsequently do 
lines[cash_price], it will pull the old value from 
lines._extra['SUM(orderline.cash_price)'] and ignore the new value stored in 
the new key. This is because Row.__getitem__ always gets the value stored in 
_extra when the key is in _extra (
http://code.google.com/p/web2py/source/browse/gluon/dal.py#3888). To enable 
the assignment, I guess you'd have to update Row.__setitem__ so it would 
update _extra when the key is in _extra (though not sure if there are any 
downsides to that).

Anthony


[web2py] Re: dal aggregation sum fields None

2011-10-23 Thread Massimo Di Pierro
You are right. I misunderstood the issue.

On Oct 23, 11:21 am, Anthony abasta...@gmail.com wrote:
 On Sunday, October 23, 2011 11:49:31 AM UTC-4, Massimo Di Pierro wrote:

  lines[cash_price]=lines(cash_price) or 0  

 I don't think that will solve the problem. That will add a new
 'SUM(orderline.cash_price)' key to lines rather than updating
 lines._extra['SUM(orderline.cash_price)']. However, when you subsequently do
 lines[cash_price], it will pull the old value from
 lines._extra['SUM(orderline.cash_price)'] and ignore the new value stored in
 the new key. This is because Row.__getitem__ always gets the value stored in
 _extra when the key is in _extra 
 (http://code.google.com/p/web2py/source/browse/gluon/dal.py#3888). To enable
 the assignment, I guess you'd have to update Row.__setitem__ so it would
 update _extra when the key is in _extra (though not sure if there are any
 downsides to that).

 Anthony


[web2py] Re: dal aggregation sum fields None

2011-10-23 Thread Anthony
On Sunday, October 23, 2011 3:16:56 PM UTC-4, Massimo Di Pierro wrote:

 You are right. I misunderstood the issue.


Do you think assignments to _extra should be enabled (transparently, not by 
directly hacking the _extra dictionary), or should _extra remain read-only? 
The current behavior is a bit mysterious -- you can seemingly make an 
assignment to links[cash_price] without receiving an error, but when you try 
to retrieve the new value, it's not there.

Anthony


[web2py] Re: dal aggregation sum fields None

2011-10-23 Thread Massimo Di Pierro
I am not happy with extra.

Currently we have three mechanisms to deal with extra fields.
table._extra, lazy virtual fields, links in grid/smartgrid. None of
them are undocumented in the book which means that for none of them we
promise backward compatibility.


Massimo

On Oct 23, 2:27 pm, Anthony abasta...@gmail.com wrote:
 On Sunday, October 23, 2011 3:16:56 PM UTC-4, Massimo Di Pierro wrote:

  You are right. I misunderstood the issue.

 Do you think assignments to _extra should be enabled (transparently, not by
 directly hacking the _extra dictionary), or should _extra remain read-only?
 The current behavior is a bit mysterious -- you can seemingly make an
 assignment to links[cash_price] without receiving an error, but when you try
 to retrieve the new value, it's not there.

 Anthony


[web2py] Re: dal aggregation sum fields None

2011-10-23 Thread Anthony
On Sunday, October 23, 2011 5:14:17 PM UTC-4, Massimo Di Pierro wrote:

 I am not happy with extra. 

 Currently we have three mechanisms to deal with extra fields. 
 table._extra, lazy virtual fields, links in grid/smartgrid. None of 
 them are undocumented in the book which means that for none of them we 
 promise backward compatibility.


Right now, Row._extra is used to store the results of expressions (such as 
aggregate functions) in selects. The key used to store the expression is the 
expression itself, and I think that does have to remain backward compatible 
(i.e., row[expression] should retrieve the value of the expression returned 
by the select, regardless of the internal implementation). The question is 
whether it should be possible to do row[expression] = some_other_value 
(i.e., alter the value returned by the select). Currently it is not possible 
without hacking _extra. We could make it possible now, which would involve 
making an assignment to _extra in Row.__setitem__, and if the internal 
implementation of _extra fields in Row objects changes in the future, 
presumably we could just make sure the new implementation also allows such 
assignments. In other words, should the API allow assignments to expression 
results in Row objects (without reference to _extra), or should they remain 
read-only?

Anthony 


[web2py] Re: dal aggregation sum fields None

2011-10-22 Thread Anthony
On Saturday, October 22, 2011 7:47:08 AM UTC-4, apple wrote:

 I am summing some data using the DAL: 
   cash_price = db.orderline.cash_price.sum() 
   lines = db(db.orderline.order_ == id).select(cash_price).first() 

 However if there are no lines then lines[cash_price] is None. So I 
 added: 
lines[cash_price]=lines[cash_price] or 0

But this does not work either. You have to do: 
lines[cash_price]=lines._extra[cash_price] or 0 

 This is OK as it works. But wouldn't it be better if the sum were 0 
 in the first place? Or if there is some logical reason for it to 
 None then one should to be able to say: 
lines[cash_price]=lines[cash_price] or 0


I don't think you necessarily want it to default to 0 whenever no records 
are found, as you might want to distinguish between that case (None) and 
when there are records but the sum is truly 0. However, it would be nice if 
the assignment above worked without needing to refer to _extra.

Anthony