John your solution is very smart too, but sometimes it could cause
some overhead, if I do actions while the user is offline or seeing
another section, the user won't notice it, but if you do it inside a
request the user may has to wait a little longer, it depends on the
complexity of the operation you want to do.
Brian & Creecode Django Custom management commands are really the same
as this:
from django.core.management import setup_environ
import settings
setup_environ(settings)
or am I wrong? I'm just running the scripts with these three lines on
top (even before the other import statements).
The apscheduler looks like a good and simple implementation for A,
thanks Guilherme.
And finally Mateus the at(if it's available) command would be a very
easy solution for A too.
On 15 dic, 11:42, David De La Harpe Golden
<david.delaharpe.gol...@ichec.ie> wrote:
> Tim Daniel wrote:
> > So how can I implement solution B? Is there a posibility to create a
> >cronon a user action that executes only one time?
>
> > NOTE: I don't want to rely on a thread that should stay alive for two
> > hours ore more inside the server memory.
>
> Well, celery uses a "celeryd" daemon process and a message queue, so
> that is a thread staying alive om the server, but it's a completely
> separate and manageable process from your web server:
>
> http://ask.github.com/celery/introduction.html
>
> It may look a little complex, but it really makes all sorts of long
> running and scheduled tasks easy and well-integrated with django.
>
> FWIW, doing something two hours after someeventis basically a one-liner:http://ask.github.com/celery/userguide/executing.html#eta-and-countdown
On Dec 19, 6:28 am, Tim Daniel <redarrow...@hotmail.com> wrote:
> Brian & Creecode Django Custom management commands are really the same
> as this:
>
> from django.core.management import setup_environ
> import settings
> setup_environ(settings)
>
> or am I wrong? I'm just running the scripts with these three lines on
> top (even before the other import statements).
They both do the above. Its just that the custom management commands
give you a little extra with it's built-in switches and such. Use
whatever system works for your needs.
Toodle-loooooooo...........
creecode
> one question: Is it capable of running on every web server
> that supports Python?
Well, it's kind of independent of the web server bits: In principle, one could
use celery plus django orm for some project that doesn't involve any web serving
at all (celery still depends on django-as-an-orm-layer-and-stuff, but not
django-as-a-web-application-server). See:
http://ask.github.com/celery/faq.html#can-i-use-celery-without-django
So it's really "where can celery run". Unix/Linux/MacOSX and probably Windows
servers where you have shell and the ability to kick off a celeryd daemon, sure.
I'd be less clear on strange setups where django itself or parts of
django can be coaxed into working for some value of working ("cloud" stuff,
jython...).
> or are there any other requirements or things to
> think about?
Well, the message queue and carrot (the binding to the message queue celery sits on top).
The message queue is a service you will have to run. It's easier than it may sound
if on on linux, since rabbitmq is probably in your distro repository. and celery
can be easy_installed, pulling in carrot.
("rabbit" probably explaining the rabbit-food naming theme...)
(Once you have the message queue and carrot available, you may also find them
useful in themselves for tieing stuff together
http://ask.github.com/carrot/introduction.html#examples )
Oh yeah, other thing:
If you're using python <2.6, you'll need to use the python multiprocessing
backport, and you currently have to watch out for an annoying bug - if you naively
install what is still the current release, you'll
get one with the bug, either use an earlier or patched version.
http://github.com/ask/celery/issues/closed/#issue/24
http://code.google.com/p/python-multiprocessing/issues/detail?id=18
(I wish they'd do another release...)
http://code.google.com/p/python-multiprocessing/issues/detail?id=21