- Zope - Zope lists

ZSyncer and subfolders
by joe 26 Jan '04

26 Jan '04

Hello, I'm trying to use ZSyncer to sync a folder on one zope to a destination subdirectory on another zope. (IOW, not necessarily with the same parent folder struture). In other words, I want to sync /foo/bar on one zope to /development/foo/bar on the other zope - and no matter what (sub)directories I place the zsyncer objects in on the two zopes, I always get an exact copy of the source's folder structure - I always get /foo/bar on the destination. I have even tried using vhosts & vhm to sync to a 'virtual' root of /development, and yet it still doesn't work - even with the ZSyncer object in '/development' on the destination, and syncing to development.myhost.com/ (which points to 'myhost.com/development' in the destination zope), I *still* get the objects dumped in the physical Zope root. I certainly assumed that, intuitively, the relative positions of the souce & dest ZSyncer objects WRT their respective zope roots would have determined the relative positions of the subsequent syncing activity - apparently not so; they start from the Zope physical root, regardless of even vhost settings. This certainly makes it impossible to sync partial directory trees, or sync multiple sites (such development, staging) to one zope site (such as production). I have searched extensively in all the archives, and cannot find this issue mentioned - although it would seem to me to be a very obvious eaarly stumbling block to adoption of ZSyncer, so perhaps I am doing something fundamentally wrong, and there is an easy solution out there to this that someone can point out to me. Thanks, Joe Joseph Wolff eRacks Open Source Systems www.eracks.com

3 2

Howto Use METAL Macros from PythonScripts?
by Johan Carlsson 26 Jan '04

26 Jan '04

I've been "all over the place" for a solution howto use METAL macros from PythonScript but I can find any. Is there anyone that can help me out? (or do I just have to fall back on old fasion DTML Methods)? -- Johan Carlsson Tel: + 46 8 31 24 94 Colliberty Mob: + 46 70 558 25 24 Torsgatan 72 Email: johanc(a)easypublisher.com SE-113 37 STOCKHOLM Skype: colliberty

3 4

inituser
by John Poltorak 25 Jan '04

25 Jan '04

Where does zope expect to find inituser? -- John

3 2

Remote access
by John Poltorak 25 Jan '04

25 Jan '04

Are there any specific access controls I need to set up to be able to use Zope on a remote computer? I'm unable to login to the ZMI although my userid and password are correct. -- John

2 1

Initial setup
by John Poltorak 25 Jan '04

25 Jan '04

I'm setting up ZOPE on a remote Red Hat system for the first time and am not clear about a couple of things involving how to run it... How do I identify which version is running? I presume I use zopectl to start it - my Zope Bible tells me to run ./start which I can't find. How do I stop it? It looks like I didn't set up the initial user correctly so can't use the ZMI. -- John

3 5

Installing Zope products through Webmin
by John Poltorak 25 Jan '04

25 Jan '04

Does anyone know if it is possible to install Zope products using Webmin? I've just started using Webmin and find it to be a really handy tool. It would be nice if I could use it for installing everything I needed to. -- John

4 7

[ANN] MailBoxer 3.0 released
by Maik Jablonski 25 Jan '04

25 Jan '04

Hi to all, I'm happy to announce a new major release of MailBoxer - the mailinglist- / newsletter- / mailarchive-framework for Zope. Many things changed in MailBoxer 3.0 - here are the most important ones: * added new universal hooks (getter/setter) for easily integrating MailBoxer into your applications or frameworks * added a sender-loop-limitation; fixed (hopefully) all outstanding issues with mailloops * added a mail-serialisation in order to avoid Read-Conflicts in heavy-duty-setups * improved archive-search * many bugfixes and cleanups... My special thanks goes to Richard Waid who contributed several patches for running MailBoxer in very large environments. Thank you, Richard! Hope to meet you at EuroPython this year. Where can I download MailBoxer 3.0? ----------------------------------- http://zope.org/Members/mjablonski/MailBoxer/ Please read the UPDATE.txt before updating MailBoxer... Where can I see all changes? ---------------------------- http://zope.org/Members/mjablonski/MailBoxer/CHANGES Where can I see a working MailBoxer? ------------------------------------ MailBoxer runs all mailinglists (+ a gateway for a newsserver) for the German Zope User Group (DZUG) (~ 20 lists with 400 hundred people subscribed and ~ 100 mails / day). If you want to have a look at the zope(a)zope.org-list mirrored by MailBoxer, visit DZUG: http://www.dzug.org/mailinglisten/zope-org-zope/ Keep zoped, Maik Jablonski

1 0

Re: [Zope] Re: database conflicts and the _p_oid missing
by Sean 24 Jan '04

24 Jan '04

Casey, I am pretty sure I understand the idea of a "write Conflict" in Zope. This is what I have been understanding: a.) Transaction 1 reads Object A b.) Transaction 2 reads Object A c.) Transaction 1 changes Object A to create Object A1 d.) Transaction 2 changes Object A to create Object A2 e.) Transaction 1 Commits Changes - saves A1 as readable state f.) Transaction 2 Attempts to Commit - raises WriteConflict g.) A._p_resolveConflict(A,A1,A2) is called to resolve h.) Resolved state is returned and saved as new readable state Else Transaction 2 is rolled back and restarted Is this a Correct description of a write Conflict? How is a ReadConflict Different? --Sean > > Message: 10 > Date: Fri, 23 Jan 2004 11:36:24 -0500 > From: Casey Duncan <casey(a)zope.com> > Subject: Re: [Zope] Re: database conflicts and the _p_oid missing > attribute bug > To: srl(a)boston.com > Cc: jeremy(a)zope.com, zope(a)zope.org, allison(a)shasta.stanford.edu > Message-ID: <20040123113624.680d6469.casey(a)zope.com> > Content-Type: text/plain; charset=US-ASCII > > On Fri, 23 Jan 2004 09:56:23 -0500 > Shane Landrum <srl(a)boston.com> wrote: > > > On Thu, Jan 22, 2004 at 11:26:23PM -0500, Jeremy Hylton wrote: > > > > > > That right in a rough sense. ZODB uses optimistic concurrency > > > control, so later transactions are aborted if they conflict with > > > already-committed ones. But the transactions actually run > > > concurrently. > > > > Could you explain this a bit more? Because we run relatively > > high-write operations on our Zope/ZEO setup, we hit ConflictErrors > > quite a bit. I'd like to understand the underlying machinery here, > > ideally so I can come up with a fix. > > Here is a simple example: > > Suppose you have an object 'somefile' that has an attribute 'data'. Now > suppose that there are two concurrent processes modifying 'somefile': > > Process 1: > somefile.data = 'Mary had a little lamb' > > Process 2: > somefile.data = 'The Quick Brown Fox...' > > The concurrency control is "optimistic" because it allows both processes > to change the same file object (there are no locks). > > Now suppose that process 1 commits the transaction. This saves 'Mary had > a little lamb' as the new file data in the ZODB. Inevitably, process 2 > also commits its transaction. The ZODB sees that the file was modified > since process 2's transaction began, and this is a conflict > (specifically a write conflict). > > When the ZODB detects a write conflict it sees if the object supports > conflict resolution (via a special method). If so, the method is called > to allow the object to try to resolve the conflict. Most objects do not > have conflict resolution, however. In this case ZODB raises a > ConflictError (thereby aborting the transaction). This error is caught > by Zope. In response, Zope retries the web request which replays the > transaction again. If it gets another ConflictError is tries again (up > to 3 times). After 3 times it gives up and returns an error to the user. > > In most cases, the first retry is sufficent. More retries are necessary > as the system becomes busier (more concurrency). This causes extra work > since many transactions need to be retried. This can exacerbate the > problem and cause performance degradation. > > Conflicts tend to center around "hotspots", objects that are changed > often by many requests. The Catalog is a classic example since it tends > to get changed everytime new content is added to the system. Content > repository folders are another example. > > Both of these "hotspots" have their own conflict resolution code (they > typically use BTree objects which can resolve many write conflicts > internally). Write conflicts tend to be pretty manageable if you > recognize hotspots and use the proper data types (like BTrees) or add > your own conflict resolution (not for the faint of heart, however). > > The more insidious kind of conflicts are Read Conflicts. They are caused > (in simple terms) when one transaction changes an object that another > concurrent transaction is about to use (These are called "dirty reads"). > You can't resolve these kinds of conflicts and they can be very tricky > to prevent especially in a busy system. Luckily ZODB 3.3 has a new > feature: "Multi-version concurrency control" (MVCC) which resolves read > conflicts (or at worst changes them to write conflicts). Once ZODB 3.3 > gets released in Zope, we can look forward to many fewer conflict > errors. > > -Casey > > > > ------------------------------ > > _______________________________________________ > Zope maillist - Zope(a)zope.org > > > > End of Zope Digest, Vol 6, Issue 38 > ***********************************

1 0

[ANN] PathIndexNG 0.1 released
by Andreas Jung 24 Jan '04

24 Jan '04

I am pleased to announce the very first release of PathIndexNG 0.1 (PING). PING is though as an efficient replacement of the standard PathIndex which is slow and inefficient. The PING implementation offers (only) a very basic prefix search for object paths which is sufficient in most cases. It does not neither 'or' nor 'and' as operator and there is no 'level' parameter like in the existing PathIndex. So you can't search for objects by subpath. All queries are prefix search (means the query starts at the root element). Download: http://www.zope.org/Members/ajung/PathIndexNG Installation: Unpack it like any other Zope product in your Products folder and restart Zope

1 0

A persistent problem -- monkey patch related?
by Dennis Allison 24 Jan '04

24 Jan '04

I asked this question to the list a while back, but the responses I got were a bit off-point. Sad to say, the issue remains unresolved. I have made some extensive mods to UserFolder and installed them with a monkey patch. The monkey patch lives in the Products folder. The __init__().py associated with the folder imports User.py, defines the methods to be changed (e.g., foo(self) defined outside a class, then imports AccssControl and InitializeClass from Globals, assigns the new method to the associated old method name in UserFolder, and then calls InitializeClass. I chose this approach because it looked to have the least impact on the existing system, but now I am not so sure. I've been getting _p_oid errors when the OODB is backing out of a transaction. Dieter has opined that it's a Zope bug, but I am not so sure. I suspect that something I have done in the monkeypatch has triggered the problem. My patch code uses PersistentMapping() and expects that the system does the right thing with respect to persistence in the new methods even though they are patched in. Can anyone shed light on the issue: Is persistence inherited by monkey patched methods?

3 8