[Zope] Zope's database capability

[Jim Penny]

On Tue, Jan 29, 2002 at 06:18:00PM -0800, schimcsig marton wrote:
> Hi Zopers,
> 
> Jim Penny wrote:
>  > Never store things in ZODB that change often (things like page counters
>  > are prime examples.)
> 
> Are there other solutions for counter-like apps than an RDBMS or the
> file system?
> (We don't wanna give Zope file system access for maximum security... )
> Do I really have to set up an RDBMS and a table for small, tabular,
> frequently changing data?
> 
> Can I do this with non_undo dbs?
> Is the write process slow because of the undo feature?

This is my take -- others can differ.

The problem is the nature of ZODB.  It works by invalidating the object
in the current place, and building a new object at the end of the
database.  Always; even if the object is of fixed, unchanging length.
Partially this gets UNDO.  Partially it is a design decision that pretty
much every object database implementer has made.  (If objects are large,
of unpredicatable size, it makes more sense to emphasize keeping the
entire object in one place than it does to worry about reusing storage.
This speeds retrieval hugely.)

Now, in-memory is certainly possible, but the page counter will be reset
to zero every time zope is reset!

This means external database or filesystem is much more practical.

Remarks:
1)  If you are running non-Windows, this is no big deal.  make sure that
zope is running non-root, and that the portion of the filesystem being
used for this is writable to zope's user and no one else.  Not perfect,
but gives you as much isolation as you are going to get anyway.  (If a
cracker can remotely break zope and get into your filesystem, you have
lots of other worries, anyway.) [And parts of the zope hierarchy are
writeable to zope's owner.  In particular, the zope/var directory must be.
If you are worried about security, make sure that none of the files or
libs in zope/lib are writable by zope.]

2) Even if you are running windows, no big deal.  For a simple page
counter, or small table, you could write an External method that opens
a single file that contains the data, parses it, and then rewrites it.
If the file is hardcoded into the method, and the attacker cannot see 
the file name, and it only reads/writes a single file per small, 
tabular, frequently changing data, your security exposure is very 
small indeed.

3) Again, you have given no indication of OS.  But it should be trivial
to set up a RDBMS on most modern OS's.  It is even easy on Windows.  In
my experience, you are going to want it anyway; why not think about the
opportunities it gives you from the start!  Just make sure that you
select a RDBMS for which there is an activly developed DA.  Hint:
if possible, look at PostGreSQL.  PoPy and pychopg are both pretty 
active and reasonably easy to work with (but not to install)!

Jim Penny

> 
> 
> Thanx,
> 
> 
>   nuon
> 
> 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )
>