[Zope-DB] Dynamically generate sql-query in ZSQL Method

[Matthew T. Kromer]

On Apr 8, 2004, at 12:22 PM, Ian Bicking wrote:

>
> I had bad dreams last night -- literally -- thinking about what this 
> means to all the code I've written or maintained in Zope, and anything 
> that involves a side-effect.
>

Unfortunately, "side effects" get left by the wayside in the 
documentation (or, one might say "what documentation?"), but there are 
a few hotspots in Zope where a side effect can really bite you in the 
ass.

Consider the security machinery, which secures the *values* you try to 
work with.  If your function is not protected with the same permissions 
as your results, your function may run, but then the results may not  
be visible by the user.  Normally your function doesn't have any side 
effects, but if it does... well, that's another spot you can get bitten 
(really, only if the side effects cause Bad Things to happen to 
transactional integrity).


> Just when you think you've found a pattern of application development 
> in Zope that works okay -- even if it's not the Right Way or a 
> sophisticated Zope way of managing things -- Zope turns around and 
> punches you in the gut.  Damn.
>
> Well, thank's for correcting me, even if you are the bringer of bad 
> news ;)

Most of the problems arise due to the requirement to do things "the 
Zope way" which are often easy, but nonobvious to people used to 
working with more traditional systems.  If you're used to having to 
commit transactions to an RDBMS, you're caught by surprise when Zope 
does it for you.

Note that under very sophisticated areas, Zope objects can support a 
conflict management interface to resolve ConflictErrors without 
retrying the request.  However, every conflicting object has to support 
the protocol, or else the whole transaction has to be re-run anyway, 
and this doesn't address Read conflicts (which occur when data you read 
to start your transaction have changed by the time you commit).

For the most part, the Zope automatic integration with RDBMS 
transactions is a GOOD thing.  Its only when you want to separate the 
two that you run into some difficulties.