Don't try to be clever

I know it's hard to resist.

ZODB's strength is it's simplicity.  If you try to outsmart ZODB and use it
in ways it's not designed for, you'll probably get burned.

If you have use cases that seem to go outside the bounds of ZODB, you have
a number of options:

   1. Ask here about how to address the use cases with ZODB.  Don't just
   present piles of code to be debugged and don't express your use cases as
   solutions in code. Be patient if we try to probe why you want to do what
   you're asking. We're not trying to make you go away. We're trying to
   understand the real requirement. When we really understand the problem
   you're trying to solve, we may be able to suggest better approaches (with
   ZODB or with something else).
   2. Sometimes, ZODB isn't the best approach. <shrug>
   3. Sometimes, you should be clever. :)  Sometimes, you have an approach
   that really is better. After all, I was innovative in many ways when I
   created ZODB.  It's good to try new things. It's a great way to grow. But
   if you go this route, the the problems you encounter are *on you.* Take
   the time to really understand the machinery you're messing with. Don't
   expect a lot of help unless you couch questions very clearly and narrowly.
   For example, don't post a traceback and ask WTF. :)

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.