I want also share I little tricks I found... I had some globals id represent variables that I reuse in many part of the app... I know globals vars is bad idea, but it the only way I found to make things DRY and fast (caching those vars in redis) instead of redoing the same query over and over to revocer ID representation.
So, the trick is to by pass the DAL with db.executesql() as I only need 2 fields, slicing remain managable and don't degrad to much the readability, but it prevent many tables definitions at every request. I could prevent those globals var, but create them only in controller that need them, but I need those python dict also in many model definition, so... Richard On Fri, Mar 24, 2017 at 11:11 AM, Richard Vézina < [email protected]> wrote: > Thanks for your answer Joe... > > My problem though is not quite that I don't want to define linked table, > but avoid define tables that should be lazy as they are not required in the > context of a given html request... I have over 150 tables in my app (some > should be merged as one as they exist cause of some original design flaw > but time and ressources had always prevent me to do it). But many > IS_IN_DB() validator involve db set which trigger linked table definition > fine, but trigger also table definition at every request, on_define > define_table() attribute is in part a solution to this problem... I suggest > that we could use smart_query() to parse "string set" to prevent triggering > table definition when someone need db set inside an IS_IN_DB() validator. > But this would only work for this particular case, on_define would remain > usefull for other cases, so it make sens to keep using it and not refactor > IS_IN_DB(), though considering that I never needed on_define callback > before but for db set IS_IN_DB() validator, and that it make code more > readable and maintainable to be able to create db_set variable inside > models files to be reused in differents validators definition for > differents tables I guess it could worth it at least in my case. > > But as it not possible to define a db_set vars and reuse it I make my app > less DRY to improve performance. If such feature come avaible later, I > would refactor again to bring back DRYness that I had before... > > But you are right it always good to step back and figure out what the big > picture. > > On Thu, Mar 23, 2017 at 4:59 PM, Joe Barnhart <[email protected]> > wrote: > >> Just a couple of philosophical comments... >> >> Whenever I find that the web2py platform is "forcing" me to code in large >> volumes and produce ugly, quirky code which I *know* will be hard to >> maintain, I stop myself and take another look at how I'm trying to >> accomplish my task. I have this philosophy that using a platform like >> web2py (or Python, or Linux, or anything) involves a certain mindset. >> Those who created and maintain the platform envisioned working with it in a >> certain way. I call that the "swimming downstream" way of working. When I >> find I am "swimming upstream" I realize that I'm not using the platform as >> intended. >> >> In this case, for instance, you want to instantiate one table but NOT >> another table which is linked to this table. That seems like a logic error >> to me. It looks like a FEATURE that lazy table instantiation will create >> BOTH tables in this case -- certainly the linked table and its definition >> should be available wherever its linker table exists. Standing on your >> head to get around this is "swimming upstream". >> >> There are numerous ways to make your site more efficient,* if efficiency >> turns out to be a problem*. Believe me, I get it. I, too, am guilty of >> "premature optimization" more often that I like to admit. But the best >> course of action is to steam ahead and get your application working the >> easiest way possible (downstream swimming). Then, and only then, locate >> any performance trouble spots and apply optimization. Lazy tables are only >> one such optimization. >> >> You heard mention of putting tables in a module. I have about 50 tables >> in my app, some with 50 fields. To instantiate all of them all of the time >> would be somewhat of a burden. So I have opted to put table creation in >> modules. If that isn't enough, I'll worry about that when I have a problem. >> >> Swim downstream. It's the only way! >> >> -- Joe >> >> >> On Monday, March 13, 2017 at 11:03:46 AM UTC-7, Richard wrote: >>> >>> Hello, >>> >>> I am analysing my app and found that many tables that I thought were >>> lazy (lazy_tables = True) are actually not... Investigating why was that... >>> I found (I think) that 'reference table_name' cause a table to be not be >>> lazy anymore as mostly all table that are referenced are not lazy... There >>> is no insight about that in the book, or I didn't find any... >>> >>> Is referenced tables can be lazy? >>> >>> I use web2py 2.14.6 build... >>> >>> There is old issue in pyDAL repo about reference and lazyness but they >>> are closed. >>> >>> Thanks >>> >>> Richard >>> >> -- >> 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. >> > > -- 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.
