Thread safety and importing db, response, session

[Mark Graves]

Hey everyone,

I could use a sanity check here from the community.

In a controller I get a record, then, I want to pass do some database calls from a module.

It seems that the least code I could write would be in models:

from gluon import current

current.db = db

Then in the module at the top

from gluon import current

db = current.db

The method I was using was passing the objects in directly to the function defined in the module, but that was overly repetitive.  No classes, just functions.

Can anyone see where I would run into problems? Is this thread safe?

Would it be better to instantiate a class with the handler similar to what I've seen elsewhere regarding model-less apps?

Thanks in advance!

-Mark

[Anthony]

No, the book warns to avoid that approach: http://www.web2py.com/books/default/chapter/29/04/the-core#Accessing-the-API-from-Python-modules

You cannot assign the thread local object to a top-level variable in the module, as it will only be assigned once upon first import.

Anthony

[Mark Graves]

Right,  I knew it looked too easy.

Thanks, Anthony!

Would it be viable to say in models (or controllers):

from gluon import current

current.db = db

Then in modules:

def my_function(current):

     db = current.db

     session = current.session

     request = current.request

     response = current.response

Then perhaps futher mimic locals with a decorator by returning them to the function and/or changing the signature? (Or would that run into the same threading problem?

Trying to avoid repeating myself...

[Anthony]

You can also just import current in the module and then refer to it directly within your function (i.e., no need to pass current as an argument to the function).

Anthony

On Sunday, December 14, 2014 11:07:48 PM UTC-5, Mark Graves wrote:

Right,  I knew it looked too easy.

Thanks, Anthony!

Would it be viable to say in models (or controllers):

from gluon import current

current.db = db

Then in modules:

def my_function(current):

     db = current.db

     session = current.session

     request = current.request

     response = current.response

Then perhaps futher mimic locals with a decorator by returning them to the function and/or changing the signature? (Or would that run into the same threading problem?

Trying to avoid repeating myself...

On Sunday, December 14, 2014 8:32:55 PM UTC-6, Anthony wrote:

[Mark Graves]

Thanks Anthony,

I saw your web2py con talk at depaul and really appreciated your understanding of the inner workings.

Would best practice be to just import current then define db = current.db?

That works correctly as long as it is not a top level variable correct?

-Mark

[Anthony]

Yes, that should do it.

Anthony

[Mark Graves]

Another sanity check, sorry to revive a dead thread.

I'm doing a whole lot of unit testing now, and factoring out a lot of code. 

I need to mock the db object, so I'm wondering:

Is it thread safe to implement functions in modules that are imported and pass a db instance into them?

ie:

in a controller:

from applications.MY_APPLICATION_NAME.modules.SOME_MODULE_NAME import foo

x = foo(db,argument)

?

[Anthony]

Sure, that's how Auth and Crud work.

Anthony

[Mark Graves]

Thanks Anthony,

Sorry, I was a bit delirious writing that =)

-Mark

On Thu, Apr 9, 2015 at 6:47 AM, Anthony <abas...@gmail.com> wrote:

Sure, that's how Auth and Crud work.

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 a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/aNDf1SgPVso/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.