I agree it is hard to imagine, but I am just the web guy...
If I dare to guess, I would say that what they want to do is improve access to
the information for the users. The two million objects are strongly
interlinked, so this is the navigation system used up to now. But why not open
it up to browsing?
For the content team, it might also be nice to use the ZMI or similar when
working with this content.
We have not been successful to create a Catalog of this many objects. The
process seemed to time out after many hours, probably hardware-bound. Also, the
size of the resulting ZODB is of concern, but we may try again with the Catalog
on a mounted database.
My general question remains: Is there a way to address the objects contained in
a BTreeFolder2 using something like an 'offset' or other identifier? Has anyone
found a strategy that scales better than getBatchObjectListing?
Thanks
Ken
--- On Mon, 11/2/09, Andreas Jung <li...@zopyx.com> wrote:
From: Andreas Jung <li...@zopyx.com>
Subject: Re: [Zope] Large BTreeFolder2 batching/pagination
To: "Ken Ara" <feedrea...@yahoo.com>
Cc: zope@zope.org
Date: Monday, November 2, 2009, 6:23 AM
What kind of practical sense does it make to batch 400k objects? I can no
imagine single usecase where one
would be interested in walking through such an amount of objects manually.
Better organize your data in a more
handy way or implement some search logic for bringing the batch size to a
number of relevant object.s
-aj
On Mon, Nov 2, 2009 at 00:04, Ken Ara <feedrea...@yahoo.com> wrote:
Under our setup, beyond 300-400,000 contained objects, the batching provided by
getBatchObjectListing becomes unusable. I've seen this problem mentioned
somewhere but never any hint of a solution.
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )
