I know what you mean. While we appreciate greatly the speed with which we could get our app going using db4o, we remain, well, perplexed at the aura of performance surrounding db4o's marketting. Our development has slowed to a crawl now as we try to scale up and end up building our own caches and think about building our own indices. All the while, it doesn't seem like we have abnormal needs (e.g. querying through a collection). It's like, either the real customers must really have a different usage scenario, or we are being to optimistic in terms of thinking we can just design our model in a natural way and expect to then be able to query it in a reasonable time. After all, db4o is groundbreaking, and relational db's are no guide, so we have trouble knowing what to expect. We only know "this 5 second query would take a millisecond in a relational db".
For example, the idea here of adding 'parent' fields. I think we could get used to it; it's just a real help to have you guys come out and say "this is what you have to do to make this work reasonably", vs. wondering what we've done wrong. Wouldn't it be great if your main documentation could list common problems and ways to work around them? Marketing might not like that too much, but they should. Smart developers look for credibility and transparency before risking their project.
Anyhow, thanks for running this forum, thanks for the fast reply, and thanks for all your hard work that is in fact making us more productive.