obouillaud wrote:
> - Why not cleaning the email before it's insertion in
the database ? I already
> do it, but I want to be sure to avoid crashing the
sending process because
you can't crash the "sending process" w/bad email, it will
only NOT send those
emails.
> someone manualy (bad) changed an adress in the database,
or everything else
> that can lead to a bad formated adress...
you need procedures, etc. to manage that sort of thing. for
instance, if your db
has triggers, you can have it verify the email when/if
somebody messes w/it.
> - splitting into chunks... what a shame !!! the gateways
are designed for such
> tasks, that is to say long running queries. The
asynchronous process is made to
> avoid the "blank loading page" of these long tasks. Do
you mean I need to make
> a gateway that handle the whole process and that calls
for example every
> thousands email another gateway that send the emails ?!?
probably several way to handle this. here's one:
one asynch gateway, one CFC, pass in query conditions &
let it work (do the
query, send the mail). instead of one monster loop of 500k,
maybe 10 of 50k
would work better. it's all the same to the user/main app--it
hands off the
processing to the gateway & goes on to do other things.
you can easily call the
gateway 10x in the main app, since everything's happening in
the gateway it's
very fast as far as the user/main app is concerned.
i'm not sure what your UPDATE query is actually used for but
you could easily
hand-off parsing send logs, etc. to an asynch gateway (could
even be the same
one that's running the email, you can specify a different CFC
to use) to handle
that. or if you really wanted to get "fancy" have a look at
sean's concurrency
app:
http://cfopen.org/projects/concurrency
i've combined gateways before. for example, SMS & asynch
gateways work very well
together (cf can melt down SMS aggregators fairly easily). so
having more than 1
gateway handle a job's not a bad idea.