I will submit the issue to github, it was a simple example of the
problem, in the original code I do more precessing.
This are the cases when the problem occours (using Version
2.10.3-stable+timestamp.2015.04.02.21.42.07 in 64 bits Ubuntu 15.04)
db.business.test = Field.Virtual(lambdarow:4)
db.business.testa = Field.Virtual(lambdarow: row.business.test)
printdb(db.business.id >0).select().first().testa
db.business.test = Field.Method(lambdarow:4)
db.business.testa = Field.Virtual(lambdarow: row.business.test())
printdb(db.business.id >0).select().first().testa
and works with:
db.business.test = Field.Virtual(lambdarow:4)
db.business.testa = Field.Method(lambdarow: row.business.test)
printdb(db.business.id >0).select().first().testa()
db.business.test = Field.Method(lambdarow:4)
db.business.testa = Field.Method(lambdarow: row.business.test())
printdb(db.business.id >0).select().first().testa()
El 28/10/15 a las 11:47, Anthony escribió:
On Wednesday, October 28, 2015 at 10:30:13 AM UTC-4, Carlos Cesar
Caballero wrote:
I can't do this:
db.business.test = Field.Method(lambdarow:4)
db.business.testa = Field.Virtual(lambdarow: row.business.test())
printdb(db.business.id <http://business.id> >0).select().first().testa
It's a bug?, a feature? or I am having a bad day?
the exception is the clasic "<type 'exceptions.AttributeError'>
'Row' object has no attribute 'testa'"
The same problem happened with two method fields or two virtual
fields and I don't want to write the same code twice...
I observe the same problem, but I cannot reproduce it with two virtual
field or two method fields (or with a method field using a virtual
field) -- only in the exact case you have shown above.
Please submit a Github issue. In the meantime, to avoid redundancy,
you can do something like:
|
deftest(row):
value =[some code]
returnvalue
db.business.test =Field.Method('test',test)
db.business.testa =Field.Virtual('testa',lambdarow:test(row))
|
Of course, in the above example, there is no reason to wrap test() in
a lambda in testa, but I assume the real lambda will include some
additional code along with the call to test().
Also, note that it is generally best to include a field name when
creating a Field.Method or Field.Virtual object, as otherwise the
"name" attribute of the virtual field will end up being "unknown",
which will cause errors in some contexts, such as SQLFORM.grid.
An extra question:
why I need to do something like:
lambdarow: row.tablename.field
something like this looks more elegant:
lambda this: this.field
just saying...
You can do:
|
lambdathis:this.tablename.field
|
I'm not sure why we require the tablename -- maybe for consistency
with the old style virtual fields, which can be applied to joins and
therefore need to include the tablename as well as the field name.
Anthony
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google
Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
Este mensaje le ha llegado mediante el servicio de correo electronico que
ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
Nacional de Salud. La persona que envia este correo asume el compromiso de usar
el servicio a tales fines y cumplir con las regulaciones establecidas
Infomed: http://www.sld.cu/
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
