Re: [Zope] Fwd: Building a fast, scalable yet small Zope application

2009-04-27 Thread Garito
2009/4/27 Tres Seaver 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Garito wrote:
> > jajajajajajajajajajajajaja
> >
> > Amazing!
> >
> > I don't know how the other list doesn't collapse using reply-to field
> > jajajajajajajajajajajajaja
>
> I said "religious" because I meant that people have strong opinions
> about which style they prefer, and are not going to change them because
> others argue for the other style.  I didn't say (or imply) that those
> who disagree with me are wrong / evil / stupid.  I *did* say that this
> list is run according to the "no-munging" rules, and that it was a
> deliberate choice, not subject to debate.


Making joke, man, that's the point about religious, isn't it?

>
>
> > What wonders me more is how belligerent some in this list are with this
> > question
>
> I don't see how my reply can be considered belligerent.  Patrick asked
> "why doesn't the list munge 'Reply-To'?", and I replied with a link to
> an explanation, along with a statement that arguing the question would
> not be fruitful.


I mix other conversations with that

>
>
> > You cause the problem,
>
> If you had actually read the link I sent, you would have learned about
> the problems caused by munging 'Reply-To'.  I have participated in
> *lots* of mailing lists since the early nineties:  those which do munge
> the header are more painful, and routinely have "oops, that was supposed
> to be a private reply" messages show up.  The damage from such messages
> is *much* higher than the occasional "forget to CC the list" stuff on
> non-munging lists.  Again, this is *opinion,* shared by lots of mailing
> list maangers / users, but certainly not by all.
>
> > at least try to don't threaten us with ban us if we
> > send you private messages by mistake
>
> I don't know what you are talking about here:  I didn't threaten to ban
> anybody.  I generally ask (politely) that people keep their replies
> on-list, and assume that the occasional off-list reply is an honest
> mistake.  I *have* set up filters (in my own mail processing) dropping
> messages from a couple of users who persist in sending me private mail
> after being asked to keep the traffic on the list.


There are people that response very rude to a mistake private message

>
>
> > This kind of things are to don't take you seriously, sorry, but this
> cause a
> > very bad impression of the people of this list
>
> I'm sorry you feel that way.


I respect the opinions, yes, nothing to say about that. I respect you, all
of you, sometimes the email is not a good way to express. I'm a little bit
critic with some of the decisions you make because I think that Zope is the
best operating system (yes, I said operating system) someone could need

I think I need to be as critic because when you decide to make a step far
the vision of Zope I see more work I need to do for myself
I see Zope as a very very smart idea, a univers for my data in a very
similar way as a human brain seems to work and when I see how you invest
your time in another direction I sufer a lot

But, yes, I know that perhaps my vision of Zope is not like yours but it
was, at least when I know Zope the people publish some products with the
same vision

In that point I want to apologize. If I never offend you: sorry, nothing
personal

>
>
>
> Tres.
> - --
> ===
> Tres Seaver  +1 540-429-0999  tsea...@palladion.com
> Palladion Software   "Excellence by Design"http://palladion.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJ9cVx+gerLs4ltQ4RAoCdAJ9xOVCuNjNoxf5uMgTeaSQhiaXMNwCgpnvR
> GHTZGcy1s0hP1/HRJPxX5xE=
> =shhQ
> -END PGP SIGNATURE-
>
> ___
> Zope maillist  -  Zope@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
>



-- 
Mis Cosas
http://blogs.sistes.net/Garito
Zope Smart Manager
http://blogs.sistes.net/Garito/670
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
Hedley Roos skrev:
> I've followed this thread with interest since I have a Zope site with
> tens of millions of entries in BTrees. It scales well, but it requires
> many tricks to make it work.
>
> Roche Compaan wrote these great pieces on ZODB, Data.fs size and
> scalability at 
> http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/catalog-indexes
> and 
> http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/fat-doesnt-matter
>   

Thanks for those links, interesting stuff.  :-)

> My own in-house product is similar to GoogleAnalytics. I have to use a
> cascading BTree structure (a btree of btrees of btrees) to handle the
> volume. This is because BTrees do slow down the more items they
> contain. This is not a ZODB limitation or flaw - it is just how they
> work.
>   

Something like Google Analytics I'd be interested in too, it wasn't the 
aim for this
thread but something that's been bobbing around in my head.  Is this 
something
you're thinking of releasing or is it "too good/bad to share"?

-Morten

-- 
Morten W. Petersen
Manager
Nidelven IT Ltd

Phone: +47 45 44 00 69
Email: mor...@nidelven-it.no

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] relstorage on zope 2.10.5

2009-04-27 Thread Shane Hathaway
Jürgen Herrmann wrote:
> the version of zopdb shipped with zope 2.10.5 is 3.7.1, so why
> does the command above try to pull an alpha release of zodb?
> can in "pin" the version of zodb to 3.7.1?

Zope includes ZODB.  You need a buildout that does not try to replace 
the version of ZODB that comes with Zope.  Furthermore, the version of 
ZODB that comes with Zope must be patched to support RelStorage.  Newer 
Zope releases will solve this problem, but Zope 2.10 users are stuck 
with this.

If you are installing Plone, you should follow the instructions here:

http://shane.willowrise.com/archives/how-to-install-plone-with-relstorage-and-mysql/

Those instructions make use of a handy "fake eggs" mechanism provided by 
the Plone recipe.  The fake eggs solution seems like the best way to use 
Buildout with Zope releases before 2.12.

Shane

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Peter Bengtsson
For huge inserts like that, have you looked at the more modern
alternatives such as Tokyo Cabinet or MongoDB?
I heard about an experiment to transfer 20 million text blobs into a
Tokyo Cabinet. The first 10 million inserts were superfast but after
that it started to take up to a second to insert each item.
I'm not famililar with how good they are but I know they both have
indexing. And I'm confident they both have good Python APIs.
Or watch Bob Ippolitos PyCon 2009 talk on "Drop ACID".

2009/4/27 Hedley Roos :
> I've followed this thread with interest since I have a Zope site with
> tens of millions of entries in BTrees. It scales well, but it requires
> many tricks to make it work.
>
> Roche Compaan wrote these great pieces on ZODB, Data.fs size and
> scalability at 
> http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/catalog-indexes
> and 
> http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/fat-doesnt-matter
> .
>
> My own in-house product is similar to GoogleAnalytics. I have to use a
> cascading BTree structure (a btree of btrees of btrees) to handle the
> volume. This is because BTrees do slow down the more items they
> contain. This is not a ZODB limitation or flaw - it is just how they
> work.
>
> My structure allows for fast inserts, but they also allow aggregation
> of data. So if my lowest level of BTrees store hits for a particular
> hour in time then the containing BTree always knows exactly how many
> hits were made in a day. I update all parent BTrees as soon as an item
> is inserted. The cost of this operation is O(1) for every parent.
> These are all details but every single one influenced my design.
>
> What is important is that you cannot just use the ZCatalog to index
> tens of millions of items since every index is a single BTree and will
> thus suffer the larger it gets. So you must roll your own to fit your
> problem domain.
>
> Data warehousing is probably a good idea as well.
>
> My problem domain allows me to defer inserts, so I have a queuerunner
> that commits larger transactions in batches. This is better than lots
> of small writes. This may of course not fit your model.
>
> Familiarize yourself with TreeSets and set operations in Python (union
> etc.) since those tools form the backbone of catalogueing.
>
> Hedley
> ___
> Zope maillist  -  z...@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Lennart Regebro
On Mon, Apr 27, 2009 at 17:57, Morten W. Petersen  wrote:
> OK.  Well, I'm concerned about how much a database would grow.  I'm thinking
> if
> I use one BTree for all the entries, would the database grow just a little
> or a lot when
> you start getting into the millions of entries when inserting one small
> item?

Growth is a problem only if you are going to modify these entries a lot.

> Mm.  Yes, Plone is a bit sluggish, that's why I want to write a purely
> Zope-based app.

Absolutely.

> Mm.  I guess I could be OK with one "index", it being the id/path of the
> object.  However,
> it would be nice to build for the future and include the ability to search
> all objects.  Maybe
> a combination of the two could work.

Yeah, for full text search you would definietly benefit from the full
text indexes that the catalog has.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Hedley Roos
I've followed this thread with interest since I have a Zope site with
tens of millions of entries in BTrees. It scales well, but it requires
many tricks to make it work.

Roche Compaan wrote these great pieces on ZODB, Data.fs size and
scalability at 
http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/catalog-indexes
and 
http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/fat-doesnt-matter
.

My own in-house product is similar to GoogleAnalytics. I have to use a
cascading BTree structure (a btree of btrees of btrees) to handle the
volume. This is because BTrees do slow down the more items they
contain. This is not a ZODB limitation or flaw - it is just how they
work.

My structure allows for fast inserts, but they also allow aggregation
of data. So if my lowest level of BTrees store hits for a particular
hour in time then the containing BTree always knows exactly how many
hits were made in a day. I update all parent BTrees as soon as an item
is inserted. The cost of this operation is O(1) for every parent.
These are all details but every single one influenced my design.

What is important is that you cannot just use the ZCatalog to index
tens of millions of items since every index is a single BTree and will
thus suffer the larger it gets. So you must roll your own to fit your
problem domain.

Data warehousing is probably a good idea as well.

My problem domain allows me to defer inserts, so I have a queuerunner
that commits larger transactions in batches. This is better than lots
of small writes. This may of course not fit your model.

Familiarize yourself with TreeSets and set operations in Python (union
etc.) since those tools form the backbone of catalogueing.

Hedley
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
Peter Bengtsson skrev:
> From experience I find that BTrees are very fast to write to and pick
> out items from. Even in the millions. (Never gone into the tens of
> millions or further)
> Also, when it comes to browsing stuff I find SQL faster and easier to
> work with. An added advantage of a RDBMS is that you get the indexing
> seamlessly built in (no need to bridge zbrain.getObject()) and it
> makes it easier to optimize and figure out which indexes help and
> which indexes slow you down which is something that is far from
> obvious with a ZCatalog approach.
>   

Right.  But wouldn't profiling indexes in Zope be as easy as wrapping the
index search method in a function that does time.time before and after
the search?  :-)

-Morten

-- 
Morten W. Petersen
Manager
Nidelven IT Ltd

Phone: +47 45 44 00 69
Email: mor...@nidelven-it.no

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
Lennart Regebro skrev:
> On Sat, Apr 25, 2009 at 13:24, Morten W. Petersen  
> wrote:
>   
>> So far, I've been contemplating disabling undo (if that's possible),
>> 
>
> I doubt that it would make a difference. The Undo functionality comes
> out of the database being logging, and changing that would mean pretty
> much a complete rewrite.
>   

OK.  Well, I'm concerned about how much a database would grow.  I'm 
thinking if
I use one BTree for all the entries, would the database grow just a 
little or a lot when
you start getting into the millions of entries when inserting one small 
item?

>> and using BTree structures, maybe segmenting objects into different groups
>> (folders) to further speed up lookups.
>> 
>
> Yes, in my experience putting small objects in to BTree structures is
> quite fast. You may be talking about BTreeFolders, and in that case I
> don't know, I haven't done any sort of performance testing on those, I
> have used BTrees directly though, and that was fast. I haven't
> compared to SQL, but others have, and ZODB itself seems according to
> those tests quite fast. We know Plone slows everything down immensly
> in any case.
>
> I don't know if BTrees get slow when they get very big, so you would
> need to test that.
>   

Mm.  Yes, Plone is a bit sluggish, that's why I want to write a purely 
Zope-based app.

Yeah, I'll have to try different storage strategies in the ZODB, to see 
if a BTreeFolder
containing BTrees in the [0-9|A-Z|a-z] ranges would do, or if I need to 
partition it
up further with BTreeFolders containing BTreeFolders.

On the one hand I'm concerned about lookup speed, on the other about 
speed of
inserts and how much the entire database will grow inserting a < 1 KB 
object.

>>  Should I consider using the ZCatalog for faster lookups?
>> 
>
> Maybe. You probably need to not only store the objects in BTrees, but
> also somehow have indexes. These you do by storing the values you want
> to search on in BTrees as well. The ZCatalog does this in a
> configurable way for you, so if you need configurability, yes. If not,
> it's probably faster to make your own indexes with your own BTrees.
>   

Mm.  I guess I could be OK with one "index", it being the id/path of the 
object.  However,
it would be nice to build for the future and include the ability to 
search all objects.  Maybe
a combination of the two could work.

-Morten

-- 
Morten W. Petersen
Manager
Nidelven IT Ltd

Phone: +47 45 44 00 69
Email: mor...@nidelven-it.no

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen

> I suggest you experiment a bit. Create 100 million objects, and do
> some of the actions you are planning to do on them.
>   

Right.  I'm thinking of taking the time to try a simple SQL based 
implementation,
as well as one in ZODB.  I need to learn more about high-speed Zope 
programming
as well as keeping my SQL skills up to date so.  :-)

-Morten

-- 
Morten W. Petersen
Manager
Nidelven IT Ltd

Phone: +47 45 44 00 69
Email: mor...@nidelven-it.no

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Fwd: Building a fast, scalable yet small Zope application

2009-04-27 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Garito wrote:
> jajajajajajajajajajajajaja
> 
> Amazing!
> 
> I don't know how the other list doesn't collapse using reply-to field
> jajajajajajajajajajajajaja

I said "religious" because I meant that people have strong opinions
about which style they prefer, and are not going to change them because
others argue for the other style.  I didn't say (or imply) that those
who disagree with me are wrong / evil / stupid.  I *did* say that this
list is run according to the "no-munging" rules, and that it was a
deliberate choice, not subject to debate.

> What wonders me more is how belligerent some in this list are with this
> question

I don't see how my reply can be considered belligerent.  Patrick asked
"why doesn't the list munge 'Reply-To'?", and I replied with a link to
an explanation, along with a statement that arguing the question would
not be fruitful.

> You cause the problem,

If you had actually read the link I sent, you would have learned about
the problems caused by munging 'Reply-To'.  I have participated in
*lots* of mailing lists since the early nineties:  those which do munge
the header are more painful, and routinely have "oops, that was supposed
to be a private reply" messages show up.  The damage from such messages
is *much* higher than the occasional "forget to CC the list" stuff on
non-munging lists.  Again, this is *opinion,* shared by lots of mailing
list maangers / users, but certainly not by all.

> at least try to don't threaten us with ban us if we
> send you private messages by mistake

I don't know what you are talking about here:  I didn't threaten to ban
anybody.  I generally ask (politely) that people keep their replies
on-list, and assume that the occasional off-list reply is an honest
mistake.  I *have* set up filters (in my own mail processing) dropping
messages from a couple of users who persist in sending me private mail
after being asked to keep the traffic on the list.

> This kind of things are to don't take you seriously, sorry, but this cause a
> very bad impression of the people of this list

I'm sorry you feel that way.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9cVx+gerLs4ltQ4RAoCdAJ9xOVCuNjNoxf5uMgTeaSQhiaXMNwCgpnvR
GHTZGcy1s0hP1/HRJPxX5xE=
=shhQ
-END PGP SIGNATURE-

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Request time grows with memory size

2009-04-27 Thread Hedley Roos
On Mon, Apr 27, 2009 at 12:40 PM, Peter Bengtsson  wrote:
> What have you done to investigate memory leaks?
> What external connectors are you using, like MySQL or LDAP?
>

It is probably not a memory leak. The graph is what I'd expect in a
garbage collection scenario (ie. Python).

Hedley
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Peter Bengtsson
>From experience I find that BTrees are very fast to write to and pick
out items from. Even in the millions. (Never gone into the tens of
millions or further)
Also, when it comes to browsing stuff I find SQL faster and easier to
work with. An added advantage of a RDBMS is that you get the indexing
seamlessly built in (no need to bridge zbrain.getObject()) and it
makes it easier to optimize and figure out which indexes help and
which indexes slow you down which is something that is far from
obvious with a ZCatalog approach.

2009/4/25 Morten W. Petersen :
> Hi,
>
> I'm considering building a large scale, but small in features site.  It
> will contain
> lots of small objects (millions, tens of millions, hundreds of millions)
> of objects,
> where each object has a couple of strings and maybe some other light
> attributes.
>
> So far, I've been contemplating disabling undo (if that's possible), and
> using
> BTree structures, maybe segmenting objects into different groups
> (folders) to
> further speed up lookups.  Scalability is also an issue, should I
> consider using
> RelStorage?  Should I consider using the ZCatalog for faster lookups?
>
> Has anyone else developed something similar?  Are there Zope product
> examples out there that fit the bill?
>
> -Morten
>
> --
> Morten W. Petersen
> Manager
> Nidelven IT Ltd
>
> Phone: +47 45 44 00 69
> Email: mor...@nidelven-it.no
>
> ___
> Zope maillist  -  z...@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Request time grows with memory size

2009-04-27 Thread Peter Bengtsson
What have you done to investigate memory leaks?
What external connectors are you using, like MySQL or LDAP?

2009/4/27 Gerhard Schmidt :
> HI,
>
> I've encounters a performance Problem with Zope. Some requests take very
> long time to process while others are served very fast. All request go for
> the URL. The time for the delayed Requests grows with the memory size of
> the Zope Process. It's direct proportional.
>
> I have generated a chart showing the request times and memory size of the
> Zope Process. The chart can be found at http://etustar.ze.tum.de/frontend.jpg
>
> Our watchdog system restarts the Zope Process when it reaches 7.3 Gig
> Memory. The physical memory of the server is 16 Gig and its only used for
> the zope Server. There are at least 7 Gig Memory free.
>
> As you can see most of the requests are delivered within 2 seconds but some
> take up to 12 seconds. The Requests monitored are the request of our
> watchdog system. These requests are send approximately every 20 sec.
>
> When I set the restart memory limit higher the request time of the delayed
> request continues to grows proportionally.
>
> This server is part of a pool of 19 Servers. All are connected to one ZEO
> server. All show the same effect.
>
> We observe the same effect with regular requests. Some are served at normal
> speed but some requests are delayed.
>
> Any idea what causes this effect and how to fix it.
>
> Greetings
>        Gerhard Schmidt
> --
> -
> Gerhard Schmidt       | E-Mail: schm...@ze.tum.de
> TU-München            |
> WWW & Online Services |
> Tel: 089/289-25270    |
> Fax: 089/289-25257    | PGP-Publickey auf Anfrage
>
>
>
> ___
> Zope maillist  -  z...@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
>
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope] relstorage on zope 2.10.5

2009-04-27 Thread Jürgen Herrmann
hi there!

today i thought i'ds give relstorage a try, esp. for it's
small startup times compared to filestorage.

i followed the instructions at 
http://pypi.python.org/pypi/RelStorage#installation
an when calling
"python2.4 setup.py install --install-lib=${INSTANCE_HOME}/lib/python"
(instance home is set of course)
if get:
-- snip --
...
Installed /home/xlhost/zope/lib/python/RelStorage-1.1.3-py2.4.egg
Processing dependencies for RelStorage==1.1.3
Searching for ZODB3>=3.7.0
Reading http://pypi.python.org/simple/ZODB3/
Reading http://wiki.zope.org/ZODB
Reading http://www.zope.org/Products/ZODB3
Reading http://zope.org/Products/ZODB3.2
Reading http://www.zope.org/Products/ZODB3.4
Reading http://zope.org/Products/ZODB3.5
Reading http://www.zope.org/Products/ZODB3.5
Reading http://www.zope.org/Products/ZODB3.6
Reading http://www.zope.org/Products/ZODB3.3
Reading http://zope.org/Products/ZODB3.1
Best match: ZODB3 3.9.0a12
Downloading
http://pypi.python.org/packages/source/Z/ZODB3/ZODB3-3.9.0a12.tar.gz#md5=96bc2b1b04baf4ed4713d3715e24dc03
Processing ZODB3-3.9.0a12.tar.gz
...
-- snip --

the version of zopdb shipped with zope 2.10.5 is 3.7.1, so why
does the command above try to pull an alpha release of zodb?
can in "pin" the version of zodb to 3.7.1?

my versions used:
- (Zope 2.10.5-final, python 2.4.4, linux2)
- Python Version 2.4.4 (#1, Aug 8 2007, 09:54:51)
  [GCC 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)]

thanks in advance and best regards,
jürgen herrmann
--
>> XLhost.de - eXperts in Linux hosting ® <<

XLhost.de GmbH
Jürgen Herrmann, Geschäftsführer
Boelckestrasse 21, 93051 Regensburg, Germany

Geschäftsführer: Volker Geith, Jürgen Herrmann
Registriert unter: HRB9918
Umsatzsteuer-Identifikationsnummer: DE245931218

Fon:  +49 (0)700 XLHOSTDE [0700 95467833]
Fax:  +49 (0)700 XLHOSTDE [0700 95467833]

WEB:  http://www.XLhost.de
IRC:  #xlh...@irc.quakenet.org

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )