Flask context inside of delayed job. #3

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants

xen commented Aug 13, 2013

I found useful to be able to access flask configuration inside of delayed job. So I implemented additional method that allow to run delayed job inside of flask context. It is already useful for me.

Owner

mattupstate commented Sep 13, 2013

I don't like this implementation because it does not provide the correct application context. It just makes a dummy app with the same configuration values when an application could be configured in many other ways such that current_app could contain some stateful information or objects. If you want an app context in a delayed job I would simply use:

from app_package import app

@job
def long_process():
    with app.app_context():
        # your job code...

xen commented Sep 13, 2013

This is true, but it is not possible to make correct context (what is correct context btw?). Same situation with all other background tasks schedulers (GAE background tasks have different). I think this is ok. This implementation allow to copy current_app configuration if you need it. If somebody don't need it, or want to have different configuration then old way can be used instead.

Owner

mattupstate commented Sep 13, 2013

I beg to differ. Please refer to the pseudo code I provided above. Additionally, refer to this example on how one might implement this with Flask and Celery.

xen commented Sep 13, 2013

Example you provided isn't only one possible. app object sometimes is hard to reach, actually your own example shows that. We use a little different approach to configure our application and modify app object properties after factory return it. That is why I added this additional decorator.

Owner

mattupstate commented Sep 13, 2013

I still don't believe this is the correct approach as it only solves your specific problem. I find it odd that you don't configure your application in the factory method. I would suggest having one function that returns an instance of a properly configured application instance. This will make it easy to have an app instance in whatever context (delayed job, management script, etc) you want.

xen commented Sep 13, 2013

I have a reasons why it made like it. Configuration depends on deployment, for example if you use Heroku you read environment variables, on test or beta server can be different databases, etc. I want to store configuration outside of code. Probably you have different setup and it fits your needs, but it is not mandatory. It is only solution I found.

Owner

mattupstate commented Sep 13, 2013

You could encapsulate these lines into a separate function to achieve what I'm talking about.

@mattupstate mattupstate closed this Jun 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment