Two substantive comments, and some editorial ones. You write that you are thinking of different schemes for generating paths and ids. I suggest one of the things you consider is whether your scheme will work if someone cuts the ZWikiZC and pastes it somewhere else in the tree. I'm not sufficiently versed in the different methods you discussed to understand their implications--they seem to involve yet more undocumented interfaces in Zope. Second, I think the facility for email notification of changes is really interesting. It seems to me that a problem with the Wiki concept (for some uses) is that they are very difficult to monitor for changes. Sending email, perhaps combined with diff, could help with this. Editorial comments: "Summary" is spelled with an "a" (not summery). "Product" is spelled with a "c" (not produkt). Since these words are prominent in the documentation, and at least one (summary) is to be a critical method, it would be good to clean this up. The "!" in the paths baffled me (e.g., "!WikiPage"). Why Catalogs distinguish metadata from indices also eludes me. It should be explained in the Z/Catalog writeup, but since it's not, it was there to bother me while I read your description. It's hazardous to claim a performance advantage without benchmarks.
Two substantive comments, and some editorial ones.
You write that you are thinking of different schemes for generating paths and ids. I suggest one of the things you consider is whether your scheme will work if someone cuts the ZWikiZC and pastes it somewhere else in the tree.
Yes, I realized a that my current design storing a WikiName lookup dictionary leads a need to update the dictionary from other object as the are move or deleted, maybe also when their added.
I'm not sufficiently versed in the different methods you discussed to understand their implications--they seem to involve yet more undocumented interfaces in Zope.
Not, really. They are discussed in the Zope 2.2 Wiki on zope.org. They are very hard to find thou.
It's hazardous to claim a performance advantage without benchmarks.
Yes, it should be scalability advantages. //Johan
I just want to check if things work the way I think (hope) it does. In a transaction, are objects attributes safe from other threads. self._v_mytemp in my request does not conflict with other requests? (I suppose the have to be otherwise REQUEST's would interfere with each other.) I know that _v_* attributes aren't persistent but do they remain active in memory and there by accessible to other requests after the transaction commit? (I suppose class attributes needs to be protected to be thread-safe? Does anybody have an example how to do that?) Regards, Johan
Johan Carlsson wrote:
I just want to check if things work the way I think (hope) it does.
In a transaction, are objects attributes safe from other threads.
self._v_mytemp in my request does not conflict with other requests?
This is correct (or it's supposed to be.) Each thread has its own copy of the objects, so in most cases, all instance attributes are thread safe.
(I suppose the have to be otherwise REQUEST's would interfere with each other.)
I know that _v_* attributes aren't persistent but do they remain active in memory and there by accessible to other requests after the transaction commit?
They do remain after the commit. But when the objects are removed from the in-memory cache the _v_* attributes will vanish.
(I suppose class attributes needs to be protected to be thread-safe? Does anybody have an example how to do that?)
You can use allocate_lock() to accomplish thread safety with class attributes. Shane
[Shane Hathaway] | Johan Carlsson wrote: | > | > I just want to check if things work the way I think (hope) it does. | > | > In a transaction, are objects attributes safe from other threads. | > | > self._v_mytemp in my request does not conflict with other requests? | | This is correct (or it's supposed to be.) What do you mean by "supposed to be"? Is it, or is it not correct?
Erik Enge wrote:
[Shane Hathaway]
| Johan Carlsson wrote: | > | > I just want to check if things work the way I think (hope) it does. | > | > In a transaction, are objects attributes safe from other threads. | > | > self._v_mytemp in my request does not conflict with other requests? | | This is correct (or it's supposed to be.)
What do you mean by "supposed to be"? Is it, or is it not correct?
It means that a correctly operating ZODB will behave this way. I suspected that Johan may have been facing some kind of ZODB bug, therefore I qualified my statement. The phrasing was designed to elicit a response if he were indeed facing a defect. Shane
| > | > I just want to check if things work the way I think (hope) it does. | > | > In a transaction, are objects attributes safe from other threads. | > | > self._v_mytemp in my request does not conflict with other requests? | | This is correct (or it's supposed to be.)
What do you mean by "supposed to be"? Is it, or is it not correct?
It means that a correctly operating ZODB will behave this way. I suspected that Johan may have been facing some kind of ZODB bug, therefore I qualified my statement. The phrasing was designed to elicit a response if he were indeed facing a defect.
I haven't experienced any problems so far, but I havn't tested it yet either. The reason I asked was to not make any stupied assumptions before starting coding. If I experience any problems I'll let you know, naturally :-) Cheers, JOhan
[Shane Hathaway] | It means that a correctly operating ZODB will behave this way. Oh, I see. Thanks for clarifying that. :)
The ZWikiZC version 0.7.3 alpha completely rely on ZCatalog for looking up WikiPages from WikiNames. No references are stored in the ZWikiZG page letting cut&paste, delete and other management actions ignore updating links. I bellew this is a more scalable solution than in the version 0.7.2 alpha. Bottle neck might be if a page contains alote of WikiNames. I also cleaned it up a bit (remove some hacky stuff from the old ZWiki). Also added are keywords, wiki_meta_types and author_ids. http://www.zope.org/Members/johanc/ZWikiZG/wiki Cheers, Johan Carlsson
The ZWikiZC version 0.7.3 alpha completely rely on ZCatalog for looking up WikiPages from WikiNames. No references are stored in the ZWikiZG page letting cut&paste, delete and other management actions ignore updating links. I bellew this is a more scalable solution than in the version 0.7.2 alpha. Bottle neck might be if a page contains alote of WikiNames. I also cleaned it up a bit (remove some hacky stuff from the old ZWiki). Also added are keywords, wiki_meta_types and author_ids. http://www.zope.org/Members/johanc/ZWikiZG/wiki Cheers, Johan Carlsson
participants (4)
-
Erik Enge -
Johan Carlsson -
Ross Boylan -
Shane Hathaway