James Henstridge wrote:
If doing a complete re-build, there is no need to SELECT first. So I
think
that the WipeDb function is still valid to have. But I could change the
code so that it's only used in the complete-rebuild case.
You said above that you want to combine the checkin db data with your
own tables above. If you're blowing away all the data on an update,
won't that screw with foreign key constraints?
You've got a point.
Having big long running transactions is definitely a problem if you
have multiple writers accessing the database. So it is generally a
good idea to commit regularly (although committing too often can
introduce performance problems itself).
On the other hand: The whole point about transactions is that you don't
end up in a half-done, strange state.
I have a habit of using "if CONSTANT == variable", to be able to catch
cases where I have written a "=" instead of "==". I feel rather strongly
about this, as I believe that it really catches bugs. The conding style
isn't all that consistent as it is, so I hope I can keep my "backwards"
equality tests.
I am guessing that you picked up this habbit in a language other than
Python. A statement like "if variable = CONSTANT: ..." is already a
syntax error in Python since an assignment is not an expression.
Hey - I learned something new about Python today. In the light of that,
I'll change the equality tests.
As Federico says in that thread, psycopg2 doesn't do connection
pooling behind your back.
He says that one _may_ set up connection pooling. The feature must be
there for a reason, i.e. be useful in some situations. So I'd prefer the
safe-for-all solution.
--
Greetings from Troels Arvin <troels@xxxxxxxx>
http://troels.arvin.dk/
|
| 
