Hi Massimo,
Just revisiting this topic, have you given any thought about my above
proposal?.
Thanks,
Carlos
Hi Massimo,
Not in my case, I only want to have the same fake/virtual/lazy fields (not
rows) in all my rows, but using 'self' to access the direct rows (instead of
via their table names), therefore my proposal above.
It would also be great to have 'access' (subclass / extend) to all other DAL
Is the goal to append fake (virtual) rows to the result of a
select(...)
Massimo
On Aug 20, 11:33 am, Carlos wrote:
> Hi Massimo,
>
> So far this is great !
>
> But, while we're on the lazy fields topic, can you implement the following
> specialized VirtualCommand (maybe named Virtual*Row*Comman
Massimo,
As you are dealing with VirtualFields, consider including some standard
properties such as:
Label, Comment, Represent, and Type.
Label is the more usable of them, specially to display headers=labels in
SQLTABLE.
In PowerTable I used something like:
@virtualsettings(label=..., type=...)
Hi Massimo,
Note also that my above proposal will improve polymorphism too, in the sense
that we can assign the same virtual LAZY fields to any (or all) tables, and
they will all use 'self' as the actual row, without even having to know any
internals (like the table name).
Let me know what you
This is all a proposal. I think we should discuss it some more. The
all business of virtual fields has been mostly motivated by needs of
the users. I have had very little use for them.
On Aug 20, 11:33 am, Anthony wrote:
> OK. When you said the old "normal" virtual fields were now "discouraged",
Hi Massimo,
So far this is great !
But, while we're on the lazy fields topic, can you implement the following
specialized VirtualCommand (maybe named Virtual*Row*Command)?:
class VirtualRowCommand(object):
def __init__(self, method, row):
self.method = method
OK. When you said the old "normal" virtual fields were now "discouraged", I
thought you were implying all virtual fields should be lazy, but sounds like
we still want the lazy/non-lazy distinction, just with a new way of doing
both (both internally and API).
Thanks for clarifying.
Anthony
O
I think we could deprecate the old virtual fields. Yet the new syntax
(for now experimental) has two APIs:
db.x.f = Field.Virtual(a.f)
db.x.g = Field.Lazy(a.g)
because one maps into row.x.f (an attribute, compute at the time of
select) and one into row.x.g() (a method to be called later). I thin
Is the plan to deprecate old style (non-lazy) virtual fields? If so, then
maybe the new lazy virtual fields shouldn't be modified with "lazy"
everywhere -- they should just be referred to as "virtual". So, the
decorator could just be "@virtualfield", and Field.Virtual() could refer to
the new l
If couse one can also do
class A():
def __init__(self,n): self,n=n
f(self,row): return row.x.id+1+self.n
g(self,row,a=1): return row.x.id+a+self.n
h(self,row,a=1,b=2): return row.x.id+a+b+self.n
a=A(7)
db.define_table('x',)
db.x.f = Field.Virtual(a.f)
db.x.g = Field.Lazy(a.g)
How about we just do this:
db.define_table('x',Field('number','integer'))
if db(db.x).isempty(): [db.x.insert(number=i) for i in range(10)]
db.x.normal_shift = Field.Virtual(lambda row: row.x.number+1)
db.x.lazy_shift = Field.Lazy(lambda row, delta=3: row.x.number+delta)
for row in db(db.x).sele
OK try:
db=DAL()
db.define_table('x',Field('number','integer'))
if db(db.x).isempty(): [db.x.insert(number=i) for i in range(10)]
from gluon.dal import lazy_virtualfield
class MyVirtualFields(object):
# normal virtual
field
def normal_shift(self): return self.x.number+1
# lazy virtua
Yes but if we use lazy we have to define and import it from somewhere.
There is another reason. Using staticmethod we can also do
class A(): pass
a=A()
a.f=lambda(instance,row,*a,**b): return 'lazy value'
a.g=lambda(instance,row,*a,**b): return 'lazy value'
a.h=lambda(instance,row,*a,**b): return
why static_method is used to define this? not better to have some @lazy
decorator?
db.define_table('x',Field('number','integer'))
if db(db.x).isempty(): [db.x.insert(number=i) for i in
range(10)]
class
MyVirtualFields(object):
# normal virtual field (backward compatible,
discouraged)
def normal_shift(self): return self.x.number
+1
I am still uneasy about this and I may still change the syntax about
the lazy virtualfields
On Aug 19, 7:32 pm, rochacbruno wrote:
> Very good! Thank you
Very good! Thank you
Notice that Virtualfields do not need any knowledge of the db object.
You can declare the class in a module (not model).
Import the module and then apply them to the tables that need them.
On Aug 19, 6:03 pm, Massimo Di Pierro
wrote:
> You asked for it so here they are: built-in lazy virtual fiel
19 matches
Mail list logo
