"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Tim Legant <[EMAIL PROTECTED]> writes: > > > we write to a disk file and once a day (late at night) run a Python > > script that iterates over all the users, inserts the contents of > > their CONFIRM_APPEND files into the database and removes the > > CONFIRM_APPEND file. If an insert fails for any reason other than a > > duplicate record, we save that address and write a new > > CONFIRM_APPEND file containing just the addresses that failed. An > > error message is printed and the output of the entire script is > > mailed to the admin. > > Oh. With all due respect, this is really a gross hack. :-)
Well, it may seem like it to you. But mail is more likely to get through quicker with this scheme than with directly writing to the database from within TMDA. The database runs on a different machine than the mail processing does, meaning the likelihood of failure when talking to the database is significantly greater than the likelihood of failure writing to the local disk, which in turn means the likelihood of deferral is greater. Also, while working on the project, I couldn't come up with an INSERT statement that would insert the data I had in TMDA as well as a piece of data from another table, in one operation. We needed to live with their pre-existing database design and I couldn't figure out how to properly insert in less than two steps. That's really not acceptable in TMDA, because how would a user plug in the code for the steps they need in their particular situation? How would TMDA know if there were only one step, or two or more? While writing this response, I think I may have just come up with a way to make it work in one step, but it needs testing. I'm no SQL expert. > This isn't something I can see most TMDA/SQL users wanting to do. I agree. This wasn't a recommendation for most TMDA users. It was the answer to your question about what we did at a particular site. > Eventually, we really should provide some SQL-append capability > similar to CONFIRM_APPEND (because as I mentioned, every user needs > this). I'm ignorant of how much effort this would take, so it can > wait until after 1.0 if you want. Partial SQL support in 1.0 is > certainly better than none at all. Given the limited time and finances, I couldn't come up with any way I was happy with to integrate this into TMDA. I know mostly how to do it in a way that doesn't particularly please me and I can put that in along with the parser additions. Then we'll at least have some support in before 1.0. Assuming I add a DB_CONFIRM_APPEND variable (which is an INSERT statement in SQL that the user must write in their config), should that take precedence over CONFIRM_APPEND, assuming they're both set? I think I'd go with DB_CONFIRM_APPEND if DB_CONNECTION is not None, otherwise CONFIRM_APPEND. Does that make sense to you? Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
