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 <[email protected]> wrote: > 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 > > > > > > > > On Saturday, August 20, 2011 12:26:15 PM UTC-4, Massimo Di Pierro wrote: > > 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 think > > we need to keep the distinction. The problem with the old syntax was > > the syntax was the verbosity but also the lack of distinction. It > > lacked a way to do the equivalent of Field.Lazy. > > > In trunk there is also an extension of the old syntax and a > > "@lazy_virtual". Perhaps this is no longer necessary. Yet it is > > constitues no overhead. > > > On Aug 20, 10:24 am, Anthony <[email protected]> wrote: > > > 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 lazy virtual field (if we're deprecating old virtual fields, we > > > might not need to bother with the new Field.Virtual() syntax for them, or > > > > maybe use something like Field.OldVirtual). > > > > Anthony > > > > On Saturday, August 20, 2011 8:56:09 AM UTC-4, Massimo Di Pierro wrote: > > > > 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).select(): > > > > print row.number, row.normal_shift, row.lazy_shift(8) > > > > > It is in trunk already, not as a replacement but as an alternative. > > > > Pros: > > > > - simpler syntax > > > > Cons: > > > > - we can only attach virtual fields to a table not to a join (even if > > > > each table in the joins will have virtual fields) > > > > - they will not appear in crud.read and table forms unless passed > > > > explicitly. (*) > > > > > (*) In principle this can be changed as one can envision adding > > > > Field.Virtual in the model and giving them attributes like a label, > > > > comment, etc. But that would require major refactoring. > > > > > On Aug 20, 7:04 am, Massimo Di Pierro <[email protected]> > > > > wrote: > > > > > 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 virtual field (because of > > > > > @staticmethod) > > > > > @lazy_virtualfield > > > > > def lazy_shift(self,row,delta=4): return row.x.number+delta > > > > > > db.x.virtualfields.append(MyVirtualFields()) > > > > > > for row in db(db.x).select(): > > > > > print row.number, row.normal_shift, row.lazy_shift(8) > > > > > > It is better? We have one new API and one import. I do not like so > > > > > much the try of adding a __lazy__ attribute to the function because, > > > > > in the future the function may be a class with a __call__ method and > > > > > te decorator would mess up class attributes.... perhaps we should > > > > > this dicusssion and tests on web2py-delevelopers > > > > > > Massimo > > > > > > On Aug 20, 6:46 am, Massimo Di Pierro <[email protected]> > > > > > wrote: > > > > > > > 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 'lazy value' > > > > > > > db.table.virtualfields.append(a) > > > > > > > Lat me give it a try anyway... > > > > > > > On Aug 20, 5:51 am, Bruno Rocha <[email protected]> wrote: > > > > > > > > why static_method is used to define this? not better to have > > some > > > > @lazy > > > > > > > decorator?
