Greg Ward said:
> The loss of a query language is irrelevant; Python becomes your query
> language.  You don't *really* enjoy embedding SQL in Python, do you?
> Unless you are a true SQL wizard, I bet you ended up using Python code
> to knit together the result of several small SQL queries to do anything
> complicated/interesting.

I find that working purely in Python is pleasant and working purely in SQL
is pleasant - whenever the tools is right for the job. What I found fairly
maddening was writting the interfaces between objects and the SQL
respository. I've used a home grown scheme and someone elses OR mapper
(not to bad actually) but the size and complexity of the code certainly
grows and its not very fun stuff to write either.

There is no doubt that ZODB makes persistance pleasant for Python
developers. I'm half way through porting my old SQL backed solution over
and its amazing how much code and cruft I have deleted in the process,
made possible by ZODB.

>
> However, the lack of real indexing infrastructure builtin to ZODB is a
> major weakness.  It's a weakness that we've lived with for over two
> years now; but we have the happy advantage that our database grows
> slower than hardware gets faster, so we've been able to stay ahead of
> the curve.  (Our worst-case brute-force crawls are typical around 1000
> to a few thousand objects.  We do have scripts that crawl our entire
> database (around 250k objects last I checked), but those run offline,
> not via the web.)  Furthermore, our entire database is around 100 MB, so
> can comfortably fit into main memory on all of our servers and most of
> our development machines.
>

This is the sort of feedback I was looking for - 'ya there's no indexing
but it hasn't mattered because...'.

Last night I cooked up a couple tests with nested objects and played with
the brute force method - it seems that I can rest fairly easy for this
application.