You might try something like this in your module:

dummy_db = DAL('sqlite:memory', do_connect=False, migrate_enabled=False)

def define_tables(db):
    db.define_table('mytable', Field('field1'), Field('field2'))

define_tables(dummy_db)

query1 = dummy_db.mytable.field1 == 'some value'
query2 = dummy_db.mytable.field2 == 'other value'

By setting do_connect=False, no connection will be made to the database. 
Note, the URI used for the dummy database does not have to be the same as 
the real database, but it should refer to the same type of DBMS (mainly to 
ensure the the proper SQL dialect is used to generate the SQL).

Then in your model and/or controller code:

from mymodule import define_tables, query1, query2

db = DAL(...)

define_tables(db)

rows = db(query1 & query2).select()

Note, with the above approach, the dummy DAL object defined in the module 
is not the same DAL object defined in the model/controller code where the 
query is executed. However, in order to generate queries in the module, we 
still need to define the tables on the dummy DAL object. So, the above 
example puts the table definition code in a function, which can be called 
within the module as well as the model/controller code in order to define 
the same tables on the real DAL object as well as the dummy object.

Finally, you should consider whether there is really much benefit to 
defining the queries in a module in this way.

Anthony

On Thursday, September 21, 2017 at 2:30:10 AM UTC-4, Brendan Barnwell wrote:
>
> On Wednesday, September 20, 2017 at 10:31:04 PM UTC-7, Massimo Di Pierro 
> wrote:
>>
>> In web2py, and in general in code that runs multithreaded you should not 
>> define variables in modules at top level and then import them because they 
>> are cached and then shared by multiple threads. That is not thread safe and 
>> will cause all kind of problems. Modules should define functions and 
>> classes, not objects. You should only import those functions and classes. 
>>
>>
> I think it is a bit extreme to say that modules can only define functions 
> and classes.  Clearly they can also contain, for instance, "constant 
> declarations" like "something = 2".  My question is whether there is a way 
> to define a query constraint as a "constant" in a similar way.
>
> An expression like "db.MyTable.myfield > 2" does not conceptually need to 
> know anything about the field, the table, or even the database at the time 
> it is created.  In this situation "query = db.MyTable.myfield > 2" would be 
> no different from a constant assignment like "MY_CONSTANT = 7".  There is 
> no reason why the expression itself needs access to any thread state.  It 
> is only when the query is actually executed that it needs to be attached to 
> a live database connection --- but that may be at a later time.  What I'm 
> asking is if there is a way to use the syntactic sugar of the DAL without 
> any connection to an actual database, just to create a query expression 
> that can be LATER attached to a database object.
>
> It appears the answer is no.  Is that what you are saying?
>

-- 
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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to