Since I seem to be the cause of all hell breaking loose over here, I thought
take the opportunity to respond, since I haven't really been given an
opportunity to do that. Since this probably going to be my only ever
posting to zope-dev, I don't feel constrained to be brief in exercising my
right
There are also set objects like OOSets and IISets that can be used in
intersection and union operations as documented in the BTrees module.
- Original Message -
From: "Jeffrey P Shell" <[EMAIL PROTECTED]>
To: "Matt Hamilton" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, Nove
On Thursday, November 29, 2001, at 04:03 AM, Matt Hamilton wrote:
> On Thu, 29 Nov 2001, Chris Withers wrote:
>
>>> I would rather avoid having to use a relational database unless I
>>> have to.
>>> Perhaps the index pluggability could be made to support different
>>> backends
>>> (like FileS
> I see an intention not to break other user folder products. Given that
> the fishbowl proposal in question is supposed to make for a very small
> change, any breakage in existing products is a bug in its implementation.
I've just checked in changes that I believe address all of the
issues (t
Thanks Mike, I've checked this in to our CVS sources.
mike hong wrote:
> I found ZODBC bug at max_rows.
>
> file name: db.py
>
> line: 230
>
> Current version is getting all rows regardless of max_rows.
>
> Fixed version is getting rows until rows are smaller than max_rows.
>
> Current version
Sorry to post here.
I posted last week on the zope list about what appears to be a new/strange security
related problem in 2.4.3
I thought it was a problem in LdapUserFolder, but jens spent more time debugging than
I did and he feels it's somewhere in the Zope security machinery.
http://colle
> > a) The change to manage_* seems to be completely arbitrary,
> since we already
> >had _do* methods that meant you didn't have to call manage_users with
> >fake submit buttons. So what is the point of having manage_ ?
>
>
> They were added in response to this fishbowl proposal:
>
> http
Jim Fulton wrote:
>
> Chris Withers wrote:
> >
> > Toby Dickenson wrote:
> > >
> > > FileStorage is 'damn fast', so almost anything is going to be slower.
> >
> > Indeed, until it runs out of RAM for its indexes ;-)
>
> I wish you would finish testing the change I made for you.
Sorry, to be cle
Steve Alexander wrote:
>
> In summary:
>
> I want to make sure that things are no worse in Zope 2.5 final than in
> Zope 2.5. Any breakage caused by this API change is a bug, and needs to
> be sorted out by Zope 2.5 final.
That should have read:
I want to make sure that the user managem
A K Milton wrote:
>
>
> a) The change to manage_* seems to be completely arbitrary, since we already
>had _do* methods that meant you didn't have to call manage_users with
>fake submit buttons. So what is the point of having manage_ ?
They were added in response to this fishbowl propos
I found ZODBC bug at max_rows.
file name: db.py
line: 230
Current version is getting all rows regardless of
max_rows.
Fixed version is getting rows until rows are smaller than
max_rows.
Current version:
while status==SQL_SUCCESS:
.
r.append(rd)
status=SQLFe
Chris Withers wrote:
>
> Toby Dickenson wrote:
> >
> > FileStorage is 'damn fast', so almost anything is going to be slower.
>
> Indeed, until it runs out of RAM for its indexes ;-)
I wish you would finish testing the change I made for you.
It should reduce the memory consumption by an order of
Yikes, it was pointed out to me that I typed "amk" instead of "akm".
Though I knew it was Andrew Milton and not Andrew Kuchling, I mixed up
the letters. (In fact, as I was typing it, I was thinking "wow, that
looks like Andrew Kuchling's monogram.")
--Paul
Paul Everitt wrote:
>
> Whew, th
On Thu, 29 Nov 2001, Chris Withers wrote:
> > I would rather avoid having to use a relational database unless I have to.
> > Perhaps the index pluggability could be made to support different backends
> > (like FileStorage et al does).
>
> Yeah, unfortunately, the difficult bit is combining querie
Whew, that email (and the preceding one in the thread) is quite a
whopper. In substance, amk raises some pretty serious issues that we
need to come to grips with very quickly.
I don't have enough information to respond right now, but trust that
we'll get a good response back today.
Neo-mode
Dario Lopez-Kästen wrote:
>
> Anyway. In case you were wondering what the previous email meant, there's
> the
> actual meaning d8)
I'm sure Andy's got a point, but we haven't got the context of those points.
Is he complaining about the change in UserFolder API in Zope 2.5?
cheers,
Chris
Casey Duncan wrote:
>
> I'm not sure I want to store the indexes in the ZODB, just index ZODB data at
> a low level.
Ah, okay, and yes, in that case, I am in complete agreement ;-)
(the level I'm aiming at is just to be able to index python objects, I'll leave
plugging that into the ZODB archit
Andreas Jung wrote:
>
> Storage of indexed data is one aspect but there is also need for components
> like
> lexers, stemmers, splitters etc. Oracle Intermedia as an example has a very
> flexible
> architecture to handle these components (for all that Oracle Intermedia
> sucks).
Hmmm... hopefull
Andreas Jung wrote:
>
> I think the software "MG" from the book "Managing Gigabytes" is GPLed and
> currently
> released as mg-1.21. Walking through the TOC of the book, it seems to be a
> very detailed
> sources about text processing and gives very much informations about
> different indexes typ
"Barry A. Warsaw" wrote:
>
> than the factor of 100 your numbers showed for you data! I would not
> make the blanket assertion that Berkeley storage is 100 times slower
> than FileStorage.
Sorry, let me clarify as well, I only meant in the context of searching and indexing...
> Let me just rei
I thought this might be intresting for discussion on zope-dev as well...
/dario
- Original Message -
From: "Andrew Kenneth Milton" <[EMAIL PROTECTED]>
To: "Andrew Kenneth Milton" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, November 29, 2001 8:45 AM
Subject: Re: [Exuserfol
21 matches
Mail list logo
