> Erik Enge wrote:
> >
> > On Fri, 27 Apr 2001, Chris Withers wrote:
> >
> > > Erik Enge wrote:
> > > >
> > > > I'm using Zope 2.3.1b1 so that shouldn't be a problem?
> > >
> > > Yes, it will be. [...]
> >
> > So the "bug" in Zope 2.3.1b1 which makes the ZODB grow dramatically is
> > gone in Zop
Erik Enge wrote:
>
> On Fri, 27 Apr 2001, Chris Withers wrote:
>
> > Erik Enge wrote:
> > >
> > > I'm using Zope 2.3.1b1 so that shouldn't be a problem?
> >
> > Yes, it will be. [...]
>
> So the "bug" in Zope 2.3.1b1 which makes the ZODB grow dramatically is
> gone in Zope 2.3.2b2?
Not so much
On Fri, 27 Apr 2001, Chris Withers wrote:
> Erik Enge wrote:
> >
> > I'm using Zope 2.3.1b1 so that shouldn't be a problem?
>
> Yes, it will be. [...]
So the "bug" in Zope 2.3.1b1 which makes the ZODB grow dramatically is
gone in Zope 2.3.2b2?
___
Erik Enge wrote:
>
> > The old (pre 2.3.1) catalog implementation was know not to be very
> > storage friendly. If a significant portion of the catalog indexes
> > would be affected by imports, then you would see a quadratic storage
> > increase.
>
> I'm using Zope 2.3.1b1 so that shouldn't be a
On Thu, 26 Apr 2001, Chris McDonough wrote:
> This level of growth doesn't seem like a sane level of growth... what
> Zope version are you using?
Zope 2.3.1b1
> > Someone told me that ZEO and bulk-adding could be a thing to look at...
>
> Isn't bulk-adding what you're doing now?
It is, but
On Thu, 26 Apr 2001, Dieter Maurer wrote:
> Are the imported object "CatalogAware"?
They are.
> The old (pre 2.3.1) catalog implementation was know not to be very
> storage friendly. If a significant portion of the catalog indexes
> would be affected by imports, then you would see a quadratic s
Erik Enge writes:
> I've just finished adding a somewhat small number of objects: 5000.
> For every 1000th object, the Data.fs seemed to grow to about 900MB; that's
> when things started going slow, in a non-linear fashion (this is more a
> hunch than something I payed much attention to).
>
Erik Enge wrote:
>
> On Thu, 5 Apr 2001, Michael R. Bernstein wrote:
>
> > I'm trying to find out of there is a point where you start getting
> > non-linear performance penalties for additional objects (storing,
> > retreiving, or indexing).
>
> I've just finished adding a somewhat small number
On Thu, 5 Apr 2001, Michael R. Bernstein wrote:
> I'm trying to find out of there is a point where you start getting
> non-linear performance penalties for additional objects (storing,
> retreiving, or indexing).
I've just finished adding a somewhat small number of objects: 5000.
For every 1000t
Concerning Zcatalog:
1. Search of vocabulary is fully matched, partial search, trancate search or
fuzzy search will be useful for searcher.
2. If we catalog all things in one catalog, then we need to make filter when
we want to search on one particular portation.
3. I would like to suggest :
> Andy McKay wrote:
> >
> > Any cataloguing and un-cataloguing of an object is expensive, c'mon you
are
> > changing all the indices, vocabulary and so on. You never notice it
normally
> > for 1 - 10 things, but run an import script of 1 and catalog each
object
> > as it gets added (rather tha
> In other words, does the time to
> store/index/reindex/retreive an object change (for the
> worse) depending on whether there are 10,000 objects,
> 100,000 objects or 10,000,000 objects stored/cataloged in
> the ZODB/ZCatalog?
I don't think it makes much of a difference. At least not a big one
Andy McKay wrote:
>
> Any cataloguing and un-cataloguing of an object is expensive, c'mon you are
> changing all the indices, vocabulary and so on. You never notice it normally
> for 1 - 10 things, but run an import script of 1 and catalog each object
> as it gets added (rather than all of th
Andy McKay wrote:
>
> Any cataloguing and un-cataloguing of an object is expensive, c'mon you are
> changing all the indices, vocabulary and so on.
Yup...
> You never notice it normally
> for 1 - 10 things, but run an import script of 1 and catalog each object
> as it gets added (rather th
Andy McKay wrote:
>
> As I said this was a year ago... but still incremental cataloging is very
> expensive.
How come? I always thought this was one of Zope's strong points as opposed to,
say, Lotus Notes' batch view buildign paradigm...
cheers,
Chris
_
hris Withers" <[EMAIL PROTECTED]>
Cc: "Erik Enge" <[EMAIL PROTECTED]>; "Michael R. Bernstein"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 09, 2001 1:59 PM
Subject: Re: [Zope-dev] 27 million objects.
> Any cataloguing and un-catalo
<[EMAIL PROTECTED]>; "Michael R. Bernstein"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 09, 2001 10:52 AM
Subject: Re: [Zope-dev] 27 million objects.
> Andy McKay wrote:
> >
> > As I said this was a year ago... but still incremental catalogin
ot;Michael R. Bernstein"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 09, 2001 7:31 AM
Subject: Re: [Zope-dev] 27 million objects.
> Zopista wrote:
> >
> > Hear, hear. The cost of the incremental cataloguing is horrific. One of
our
> > dev
Zopista wrote:
>
> Hear, hear. The cost of the incremental cataloguing is horrific. One of our
> developers when we started with Zope a year ago wrote a great script that
> imported a bunch, restarted zope, packed it, restarted it, imported a bunch
> more to get optimal performance. We dont do it
> I don't know, but I feel that is the case. Actually, I know it is the
> case, but I don't know what is causing it. I know what isn't helping
> though; CatalogAwareness. I added 2000 objects with XML-RPC. No other
> queries were done during that period. For each object about 70 DTML
> Method
On Thu, 5 Apr 2001, Michael R. Bernstein wrote:
> I'm trying to find out of there is a point where you start getting
> non-linear performance penalties for additional objects (storing,
> retreiving, or indexing).
I don't know, but I feel that is the case. Actually, I know it is the
case, but I
ot;Erik Enge" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 05, 2001 7:24 AM
Subject: Re: [Zope-dev] 27 million objects.
> Erik Enge wrote:
> >
> > The programmer solving our problems with the post codes has solved it in
a
> > different way
Erik Enge wrote:
>
> The programmer solving our problems with the post codes has solved it in a
> different way than what I would've done (his method is way superior), so
> we're not ending up adding all addresses as Zope Objects.
Oh well. Does anyone else have any setups that store truly
massiv
23 matches
Mail list logo
