Dear Ross - I strongly encourage you to switch to the zope@zope.org mailing list as this one is dedicated to next-generation product enhancement as opposed to peer user assistance. The approach you are taking seems a bit convoluted and I, for one, do not understand the business/project objectives reason to construct the objects as you do and create the acquisition cvhallenge you hope to solve. Perhaps you can elaborate on the goal you hope to accomplish so others can suggest the better tools and object containment structure to use. It seems earlier design decisions have taken you to solving issues that might not exist with an alternative, more-naturally-zope-like approach. Gary Message: 2 Date: Wed, 24 Jul 2002 13:05:59 -0700 To: "Matthew T. Kromer" <matt@zope.com> Cc: Ross Boylan <RossBoylan@stanfordalumni.org>, zope-dev@zope.org Subject: Re: [Zope-dev] Refresh trashes acquisition From: Ross Boylan <RossBoylan@stanfordalumni.org> On Wed, Jul 24, 2002 at 10:38:44AM -0400, Matthew T. Kromer wrote:
Ross Boylan wrote:
I find that when I refresh my product it destroys some of the containment relationships. Things start failing, and as far as I can tell the only recovery is to completely rebuild the object.
This is a big problem, and if anyone could explain what is going on and how to avoid it I would appreciate it.
Here is the result of aq_chain before the refresh: [<RankQuestion instance at 8dd5620>, <OriginalSuborder instance at 8c9f8d8>, <EMailBallot instance at 8dfc870>, <__FactoryDispatcher__ instance at 8e73770>, <ProductDispatcher instance at 83f0618>, <Folder instance at 8d5733
and after [<RankQuestion instance at 8dee2d0>]
[...]
Hmm, while what you're referring to is "refresh" in the sense of a product reload, it's important to first state that *no* acquisition is expected to survive between transactions.
Each transaction must separately acquire its objects; if you try to pass wrapped objects between transactions or threads you're going to end up in trouble.
Secondly, when a product is refreshed, the extensionclass module will probably create new base classes for any ExtensionClass derived class file. I dont *think* you can get much mileage out of knowing the id (address) of a class now, but be aware that a refresh will likely cause that address to change. I have seen some bizarre errors where module "constants" changed because of a reload, and "is" tests broke because "is" tests the object address.
None of this is explicitly what you're asking about -- but I think what you're trying to do is in violation of the "no wrapped objects should be stored past a transaction boundary" rule.
However, I may be misreading your question too -- which is why I mention those two rules above so YOU can see if they make sense in your context.
The first point is definitely relevant, and explains why I am having problems. It's surprising what I'm doing is workign at all! The class redefinition in the second point might explain some of the timing of the problems, but it's the instances, not the classes that I am interested in. The acquisition I want to do is in the object containment hierarchy, but URL of the request will also have this hieararchy. Is there some way I can grab it at the appropriate time? Your comments also clarify a point that was unclear to me from the documentation on acquisition. The documents refers to the object containment hierarchy and the request path hierarchy, and recommend keeping them consistent. But I didn't understand which hierarchy it used if they weren't. Apparently only the request path matters. It may be helpful to say more about the exact relations in my case: [indentation indicates containment in this diagram; capital letters are for objects] B ballot Q1 question R1a response R1b response SR suborder of responses see below for suborders R1a R1b (same objects as the R1's above) Q2 question ... NQ "namestyle" of questions (determines labeling) NR namestyle of responses SQ suborder of questions (sequential, random, ...) this suborder contains a list of the same questions Q1, Q2, etc that the ballot B holds. It also the name of the namestyle, to be acquired from the container. Generally, B and maybe Q will be in my request path, and the other items are not. I ask the suborders for list of items, so they give me back a list of Q's or R's. The items in those lists were the ones I was trying to wrap. At the most extreme case, I get a response R from the suborder list of a question Q, and I get the Q from the suborder of the ballot. So I't two levels removed from my original context, the ballot B, that has the namestyle I'm trying to acquire. The suborder on the Question needs to acquire the namestyle from the Ballot. Finally, I may be making an overly conservative assumption about ObjectManagers. Without it, the suborders would not need to hold onto object references. It's easiest to explain this with a specific example. I want to be able to recover the original order questions were entered into the ballot. Ballot is a subclass of ObjectManager. I believe I am not allowed to make any assumptions about the order its items will be returned by objectItems(), so I am using the suborder to track that. P.S. I also assume that objectItems('type') gets only objects of that type, not subtypes. Does anyone know if that's so? --__--__-- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev (To receive general Zope announcements, see: http://lists.zope.org/mailman/listinfo/zope-announce For non-developer, user-level issues, zope@zope.org, http://lists.zope.org/mailman/listinfo/zope ) End of Zope-Dev Digest
On Thu, Jul 25, 2002 at 12:09:35PM -0700, Gary Speer wrote:
Dear Ross - I strongly encourage you to switch to the zope@zope.org mailing list as this one is dedicated to next-generation product enhancement as opposed to peer user assistance.
I thought this list was for developers, including product developers, while the other was for zope users. Isn't that the case?
The approach you are taking seems a bit convoluted and I, for one, do not understand the business/project objectives reason to construct the objects as you do and create the acquisition cvhallenge you hope to solve. Perhaps you can elaborate on the goal you hope to accomplish so others can suggest the better tools and object containment structure to use. It seems earlier design decisions have taken you to solving issues that might not exist with an alternative, more-naturally-zope-like approach.
Gary
I suspect you are right that I may be going about this in an un-Zope like way, so let me describe the goals at a slightly higher level. My immediate goal is to be able to do votes for a non-profit organization I'm in. Existing tools that I have found (include both non-Zope things and the Zope Poll product) are not quite flexible enough. For example, I want to have several question in one poll (eliminatess most of the non-Zope things) and I want to be able to have people rank alternatives for some of the questions (Poll product doesn't have this). I'm trying to make something that has lots of little bits that can be combined flexibly. For example, one can combine a particular style of question (yes/no vs ranking) with a way of tabulating the votes (instant-run-off vs ranked pairs for ranked questions). The part that's giving me trouble relates to how subitems are handled. Questions are subitems of a Ballot, and Response are subitems of Questions. There are two choices 1) what order should the items be presented in (e.g., original order or a random order)? 2) how should they be labelled? This in turn has two parts: do you want arabic, roman, or letters for the labels, and what decoration around that do you want--e.g., "Question xxx:" vs "Issue xxx)". It seems natural to allow some of these options to be specified at a high level of containment. For example, one might have a preferred numbering style for questions and another for responses that are set at the level of the Ballot (or even higher, possibly). Then, if you wanted to, you could override these lower down. Specifically, each question determines how to number its responses, but the style it uses for numbering the responses will typically come from a higher level. This style of containment and optional overriding seemed to me exactly what acquisition was all about, so I tried to do it with acquisition. But it didn't work. Based on previous responses, I've implemented a containment hierarchy by hand. This works. Almost surely there is a better way.
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
I thought this list was for developers, including product developers, while the other was for zope users. Isn't that the case?
Nope, but its hould be for product developers, because there isn't one. :-)
It seems natural to allow some of these options to be specified at a high level of containment. For example, one might have a preferred numbering style for questions and another for responses that are set at the level of the Ballot (or even higher, possibly). Then, if you wanted to, you could override these lower down.
Yup. And you can to that by setting and acquiring properties. No problemo.
This style of containment and optional overriding seemed to me exactly what acquisition was all about, so I tried to do it with acquisition. But it didn't work.
I haven't really understood what didn't work, because I have been on vacation and not following this thread very closely...
Based on previous responses, I've implemented a containment hierarchy by hand.
"By hand"? You mean that instead of having your objects being Zope objects added from the Add drop down box, they are pure python objects and added only by code?
On Fri, Jul 26, 2002 at 01:47:12AM +0200, Lennart Regebro wrote:
From: "Ross Boylan" <RossBoylan@stanfordalumni.org> [snip]
This style of containment and optional overriding seemed to me exactly what acquisition was all about, so I tried to do it with acquisition. But it didn't work.
I haven't really understood what didn't work, because I have been on vacation and not following this thread very closely...
Previously in this thread I was advised that acquisition relationships don't persist across transaction boundaries, and this was consistent with the failures I was getting when trying to use it (actually, the relations only got zapped when I did a product refresh, but that was enough to make them unusable, particularly with the word I couldn't count on them in general).
Based on previous responses, I've implemented a containment hierarchy by hand.
"By hand"? You mean that instead of having your objects being Zope objects added from the Add drop down box, they are pure python objects and added only by code?
Not that much by hand; in fact they are mostly subclasses of SubItem or ObjectManager. The by hand part is that I have an explicit _container variable that I set in my classes, and various methods that support using it. So when I want something that might be in a container, I use those methods to get it rather than relying on acquisition.
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
Previously in this thread I was advised that acquisition relationships don't persist across transaction boundaries, and this was consistent with the failures I was getting when trying to use it
Sure, so you shouldn't create your own acquisition containment and expect it to survive over transactions. But the acquisition created by you creating Zope objects in the ZODB via the ZMI (or doing the same programatically) does of course survive transactions.
(actually, the relations only got zapped when I did a product refresh,
The refresh in Zope 2.5.1 is unusable, but I haven't figured out why yet, and nobody seems to be able to tell me. I don't have the problem that acquisition stops working. However, each time I do a refresh, some globals disappear, like referenses to other modules and stuff.
Not that much by hand; in fact they are mostly subclasses of SubItem or ObjectManager. The by hand part is that I have an explicit _container variable that I set in my classes, and various methods that support using it. So when I want something that might be in a container, I use those methods to get it rather than relying on acquisition.
Ah, OK. Yes, that would work too. But aqcisition does work. Maybe your problem just was that refresh is f*ck*d up... I'm going to try and remove the code from 2.5.1 that does refresh and put in the old refresh product instead, and see if that helps.
On Fri, Jul 26, 2002 at 09:34:28AM +0200, Lennart Regebro wrote:
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
Previously in this thread I was advised that acquisition relationships don't persist across transaction boundaries, and this was consistent with the failures I was getting when trying to use it
Sure, so you shouldn't create your own acquisition containment and expect it to survive over transactions. But the acquisition created by you creating Zope objects in the ZODB via the ZMI (or doing the same programatically) does of course survive transactions.
I don't follow that last paragraph. Does it mean 1. acquisition created by a.__of__(b) doesn't survive transactions. 2. a.b only does acquisition if a is the active object that is being published (or perhaps only if a is a newly instantiated product instance). 3. Acquisition contexts only stay around objects that subclass the relevant Zope classes (Persistence and/or Acquisition). If the statement just means that containment only survives for subclasses of Zope objects that are stored in ZODB, that's not the issue. The containment relations that got nuked were in ZODB. Some of the objects involved were created using product add; all of them subclassed the relevant Zope classes (hmm, unless it matters that PersistentList doesn't have acquisition). To recap the actual relations, where indentation indicates containment: b Ballot n NumberStyle sq Suborder of questions lq PersistentList q Question q Question (same ones as in lq above) sr Suborder of responses lr PersistentList r response r Response (same as in lr above) For simplicity, I show only a single question and response; there are many. Now, in this story b and q are full-fledged products, created using the regular add product procedure of ZMI. b and q programmatically create the other objects. n, sq, and sr all get added to their containers with _setObject, and they are subclasses of Item. All classes inherit from Persistent, and all but PersistentList inherit from Acquisition.Implicit. I get a q from lq (i.e., not the original context it was created in) and then try to do acquisition from that q's sr back up to b (n is the thing I'm trying to get). The q's in lq seemed to retain their original aquisition context (i.e., b) until I refreshed. I then tried setting it explicitly with __of__, but this didn't work either. The stuff below points to a simpler theory, one which is definitely consistent with my experience:
(actually, the relations only got zapped when I did a product refresh,
The refresh in Zope 2.5.1 is unusable, but I haven't figured out why yet, and nobody seems to be able to tell me. I don't have the problem that acquisition stops working. However, each time I do a refresh, some globals disappear, like referenses to other modules and stuff.
P.S. Since I started this thread in zope-dev, and since there seems at least some argument it should stay here, I'll continue it here. Those with a fine eye for detail might note that I have posted a question to zope, not zope-dev, in the past couple of weeks, so I am trying to use the lists appropriately. The more I think about acquisition, the less I think I understand it. My original mental model of was someting like the containment hierarchy I've implemented by hand, so that if b is in a b always knows that its acquisition context is a. But the docs actually say acquisition context is from the access path, so a.b has it but b doesn't. On the third hand, my original code was like this: class MyClass(ObjectManager, ...): def _setOb(self, id, obj): ObjectManager._setOb(self, id, obj) self.myPersistentList.append(obj) and this did work intermittently, even though obj is not accessed through self when added to the PersistentList. I also tried the following for the last line: self.myPersistentList.append(self,obj.__of__(self)), but it didn't help.
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
I don't follow that last paragraph. Does it mean 1. acquisition created by a.__of__(b) doesn't survive transactions.
Correct.
2. a.b only does acquisition if a is the active object that is being published (or perhaps only if a is a newly instantiated product instance).
I dont' understand this sentence. Are you punishing me for being impossible to understand? :-)
3. Acquisition contexts only stay around objects that subclass the relevant Zope classes (Persistence and/or Acquisition).
This is also correct.
If the statement just means that containment only survives for subclasses of Zope objects that are stored in ZODB, that's not the issue. The containment relations that got nuked were in ZODB. [...] The q's in lq seemed to retain their original aquisition context (i.e., b) until I refreshed.
They should retain this after refresh too.
P.S. Since I started this thread in zope-dev, and since there seems at least some argument it should stay here, I'll continue it here.
Do so. It is strictly speaking off-topic, but I'm covertly trying to make it into a amailing list for developing *with* zope. :-) There is no such mailing list, and one is needed. The development *of* Zope can be (and indeeed largely is) discussed in the zope-coders list. If you post questions that need guru-attention, then it will drown in zope@zope.org. And thats not just a bad thing, they high traffic on zope@zope.org is there because a lot of people is using Zope, which is good!
The more I think about acquisition, the less I think I understand it. My original mental model of was someting like the containment hierarchy I've implemented by hand, so that if b is in a b always knows that its acquisition context is a. But the docs actually say acquisition context is from the access path,
Yes, so you if you have this tree: A b C d You can access b through /A/b or /C/Ab or /C/d/A/b and it will acquire the things in this path. This is can be used to create neat and magic things, but is easy to f*ck up. :-)
doesn't. On the third hand, my original code was like this: class MyClass(ObjectManager, ...): def _setOb(self, id, obj): ObjectManager._setOb(self, id, obj) self.myPersistentList.append(obj) and this did work intermittently, even though obj is not accessed through self when added to the PersistentList. I also tried the following for the last line: self.myPersistentList.append(self,obj.__of__(self)), but it didn't help.
I'm not sure if you this way will get two references to the object or two copies of it, but you att it both directly to the MyClass instance, and to its persistent list, which I don't see the point of doing.
On Sat, Jul 27, 2002 at 12:26:04AM +0200, Lennart Regebro wrote:
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
I don't follow that last paragraph. Does it mean 1. acquisition created by a.__of__(b) doesn't survive transactions.
Correct. Just to be sure I understand: so if c is persistent, and I say c.d = a.__of__(b)
and then a few transactions later I come back and get c.d, I am not going to find it's a.__of__(b)? And also, does this mean that c.d = b.a also will not work? Or is it only the __of__ that has the problem?
2. a.b only does acquisition if a is the active object that is being published (or perhaps only if a is a newly instantiated product instance).
I dont' understand this sentence. Are you punishing me for being impossible to understand? :-)
Just proving the impossibility of coummunication.:) The intended meaning is this: suppose Zope has invoked the method foo on the object a. Then a.b in foo (or, better, the expression self.b) does acquisition, but if I run off and pull an object c from the database, c.d will not have acquisition. Is that what you meant to say?
3. Acquisition contexts only stay around objects that subclass the relevant Zope classes (Persistence and/or Acquisition).
This is also correct.
Clearly subclassing from Acquisition and Persistent is a necessary condition for storing acquisition contexts. Is it also sufficient? The statement 1 above seems to imply not, and the earlier statement (by someone else) that acquisition does not survive transaction boundaries goes further. As I understood it, it meant that it is impossible to store acquisition contexts reliably. As I understand your final sentence in the next excerpt, you are saying that it should be possible to store acquisition contexts across transaction boundaries, but problems with refresh are messing things up. So I think there is a disagreement about the theoretical capabilities of acquisition.
If the statement just means that containment only survives for subclasses of Zope objects that are stored in ZODB, that's not the issue. The containment relations that got nuked were in ZODB. [...] The q's in lq seemed to retain their original aquisition context (i.e., b) until I refreshed.
They should retain this after refresh too.
[snip]
doesn't. On the third hand, my original code was like this: class MyClass(ObjectManager, ...): def _setOb(self, id, obj): ObjectManager._setOb(self, id, obj) self.myPersistentList.append(obj) and this did work intermittently, even though obj is not accessed through self when added to the PersistentList. I also tried the following for the last line: self.myPersistentList.append(self,obj.__of__(self)), but it didn't help.
I'm not sure if you this way will get two references to the object or two copies of it, but you att it both directly to the MyClass instance, and to its persistent list, which I don't see the point of doing.
In either case, I can't see why a duplicate copy would be created. I am keeping a separate list for two reasons. First, I don't trust ObjectManager to retain the original sequence in which the objects were entered (since the API docs indicate no such guarantee). Second, I don't trust the ObjectManager getItems('type') method to recover objects that are subclasses of 'type' as well as 'type'. The actual code does a fake subclass test (since isinstance doesn't work with extension classes--aargh) and only puts some items in the persistent list.
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
Just to be sure I understand: so if c is persistent, and I say c.d = a.__of__(b)
and then a few transactions later I come back and get c.d, I am not going to find it's a.__of__(b)?
I'm not 100% sure, I have only used __of__ in non.persistent ways, but I don't think it would work. It's not ment to work anyway. :-)
And also, does this mean that c.d = b.a also will not work?
It will work alright, but you won't find b in the acquisition when you access d.
The intended meaning is this: suppose Zope has invoked the method foo on the object a. Then a.b in foo (or, better, the expression self.b) does acquisition, but if I run off and pull an object c from the database, c.d will not have acquisition. Is that what you meant to say?
It's too late here, I have to think about that tomorrow. :-)
Clearly subclassing from Acquisition and Persistent is a necessary condition for storing acquisition contexts. Is it also sufficient? The statement 1 above seems to imply not, and the earlier statement (by someone else) that acquisition does not survive transaction boundaries goes further. As I understood it, it meant that it is impossible to store acquisition contexts reliably.
Well, you can't *store* them any differently than how you store them in the ZODB, thats correct. If you access /a/b/c that thats how your acquisition path will look, and you can't put in the object /d/e in that acquisition path permanently by storing it. If you need it there you either need to access c through /d/e/a/b/c, or you need to push e into the right place in the acqusition. We do the latter in our templating system, where we push a couple of objects inbetween the document and the documents parent to get the templates into actions.
On Sat, Jul 27, 2002 at 12:26:04AM +0200, Lennart Regebro wrote:
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
I don't follow that last paragraph. Does it mean 1. acquisition created by a.__of__(b) doesn't survive transactions.
Correct. Just to be sure I understand: so if c is persistent, and I say c.d = a.__of__(b)
and then a few transactions later I come back and get c.d, I am not going to find it's a.__of__(b)?
What you will find is that you are leaking acquisition wrappers at the speed of light. (You will _probably_ find the data you want, as well).
3. Acquisition contexts only stay around objects that subclass the relevant Zope classes (Persistence and/or Acquisition).
This is also correct.
Clearly subclassing from Acquisition and Persistent is a necessary condition for storing acquisition contexts. Is it also sufficient? The statement 1 above seems to imply not, and the earlier statement (by someone else) that acquisition does not survive transaction boundaries goes further. As I understood it, it meant that it is impossible to store acquisition contexts reliably.
Don't store acquisiton contexts. This is badness. I still don't understand why you would want to... If all you need is an ordered ObjectManager, I believe I recall one, called OrderedObjectManager (Or something like that). If not, they are very easy to simulate - Don't give the user access to set the ID of the object, auto generate them as sequence numbers (For example - Q010, Q020... etc)
As I understand your final sentence in the next excerpt, you are saying that it should be possible to store acquisition contexts across transaction boundaries, but problems with refresh are messing things up. So I think there is a disagreement about the theoretical capabilities of acquisition.
Acquisiton should really be considered an ephemeral thing, caused BY observation, like a rainbow. Don't try to store it, but if you set up the correct conditions, it will be there when you expect it.
I'm not sure if you this way will get two references to the object or two copies of it, but you att it both directly to the MyClass instance, and to its persistent list, which I don't see the point of doing.
In either case, I can't see why a duplicate copy would be created.
Read up on pickling and shelves - ZODB is based on that (Although it is much more complex and advanced).
I am keeping a separate list for two reasons. First, I don't trust ObjectManager to retain the original sequence in which the objects were entered (since the API docs indicate no such guarantee). Second, I don't trust the ObjectManager getItems('type') method to recover objects that are subclasses of 'type' as well as 'type'. The actual code does a fake subclass test (since isinstance doesn't work with extension classes--aargh) and only puts some items in the persistent list.
If you don't like what getItems does, override it in your subclass... Adrian...
On Saturday 27 Jul 2002 12:32 am, Ross Boylan wrote:
On Sat, Jul 27, 2002 at 12:26:04AM +0200, Lennart Regebro wrote:
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
I don't follow that last paragraph. Does it mean 1. acquisition created by a.__of__(b) doesn't survive transactions.
Correct.
Just to be sure I understand: so if c is persistent, and I say c.d = a.__of__(b)
This is storing an acquisition wrapper as an attribute of c. acquisition wrappers are not persistent. This will raise an exception if you try to store c in ZODB.
and then a few transactions later I come back and get c.d, I am not going to find it's a.__of__(b)?
If you are trying to store it in ZODB, no. If you are trying to store it in a global variable, maybe. The answer would be "yes" except for products like Refresh that stomp on global variables.
And also, does this mean that c.d = b.a also will not work? Or is it only the __of__ that has the problem?
no different.
On Mon, Jul 29, 2002 at 07:58:22AM +0100, Toby Dickenson wrote:
On Saturday 27 Jul 2002 12:32 am, Ross Boylan wrote:
On Sat, Jul 27, 2002 at 12:26:04AM +0200, Lennart Regebro wrote:
From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
I don't follow that last paragraph. Does it mean 1. acquisition created by a.__of__(b) doesn't survive transactions.
Correct.
Just to be sure I understand: so if c is persistent, and I say c.d = a.__of__(b)
This is storing an acquisition wrapper as an attribute of c.
acquisition wrappers are not persistent. This will raise an exception if you try to store c in ZODB.
I was able to store these things without raising an exception, though not with the ability to reconstitute them reliably. My case was, however, subtly different. a.__of__(b) got put in a PersistentList, which is essentially [] with a little extra help: ------------------------------------- # This code is a copy of the Python UserList.py, updated to support # persistence. from Persistence import Persistent class PersistentList (Persistent): isAPersistentList = 1 def __init__(self, lst=None): if lst is None: self.data = [] else: self.data = list(lst) -------------------------------------- Either this case is different, or it is not the case that attempting to store and acqusition wrapper raises an exception (in Zope 2.5.1).
Ross Boylan <RossBoylan@stanfordalumni.org> wrote:
My case was, however, subtly different. a.__of__(b) got put in a PersistentList, which is essentially [] with a little extra help: ------------------------------------- # This code is a copy of the Python UserList.py, updated to support # persistence.
from Persistence import Persistent
class PersistentList (Persistent):
isAPersistentList = 1
def __init__(self, lst=None): if lst is None: self.data = [] else: self.data = list(lst)
This is not a correct PersistentList. Your object won't get stored to ZODB upon l.append(xx) or l.update. There is a correct PersistentList in the ZODB package of Zope 2.6 (in CVS). Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
I missed this in all the excitement, and have a follow-up below. On Tue, Jul 30, 2002 at 04:57:07PM +0000, Florent Guillaume wrote:
Ross Boylan <RossBoylan@stanfordalumni.org> wrote:
My case was, however, subtly different. a.__of__(b) got put in a PersistentList, which is essentially [] with a little extra help: # This code is a copy of the Python UserList.py, updated to support # persistence.
from Persistence import Persistent
class PersistentList (Persistent):
isAPersistentList = 1
def __init__(self, lst=None): if lst is None: self.data = [] else: self.data = list(lst)
This is not a correct PersistentList. Your object won't get stored to ZODB upon l.append(xx) or l.update.
There is a correct PersistentList in the ZODB package of Zope 2.6 (in CVS).
Florent
That was just the first few lines of the class definition to give a flavor. Was your remark that it was wrong based on the assumption it was the entire implementation, or is there something obviously wrong with the part you see?
Ross Boylan wrote:
That was just the first few lines of the class definition to give a flavor. Was your remark that it was wrong based on the assumption it was the entire implementation, or is there something obviously wrong with the part you see?
Nothing wrong with the visible parts, how did you implement the append (and other) methods? cheers, Chris
On Sat, Aug 10, 2002 at 10:25:32AM +0100, Chris Withers wrote:
Ross Boylan wrote:
That was just the first few lines of the class definition to give a flavor. Was your remark that it was wrong based on the assumption it was the entire implementation, or is there something obviously wrong with the part you see?
Nothing wrong with the visible parts, how did you implement the append (and other) methods?
cheers,
Chris
I didn't implement it, though I can't remember where I got it from. I think it's OK. For example, here's append def append(self, item): self.data.append(item) self._p_changed = 1 I hope that's not a ZODB 2 ism also!
Ross Boylan wrote:
I didn't implement it, though I can't remember where I got it from. I think it's OK. For example, here's append
def append(self, item): self.data.append(item) self._p_changed = 1
That looks okay...
I hope that's not a ZODB 2 ism also!
not sure what you mean by this... cheers, Chris
Ross Boylan <RossBoylan@stanfordalumni.org> wrote:
That was just the first few lines of the class definition to give a flavor. Was your remark that it was wrong based on the assumption it was the entire implementation, or is there something obviously wrong with the part you see?
Yes, I thought this was your whole implementation. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Gary Speer wrote:
I strongly encourage you to switch to the zope@zope.org <mailto:zope@zope.org> mailing list
Why?
as this one is dedicated to next-generation product enhancement as opposed to peer user assistance.
Reason rejected... Question was technical and was dedicated to zope-dev list.
The approach you are taking seems a bit convoluted and I, for one, do not understand the business/project objectives reason to construct the objects as you do and create the acquisition cvhallenge you hope to solve.
Of course there are questions of software design and questions of implementation. There is probability that design is not perfect but technical question remains. Even with poor (Ross, note, I do not tell that it is now)design there should not be technical problem with implementation.
Perhaps you can elaborate on the goal you hope to accomplish so others can suggest the better tools and object containment structure to use. It seems earlier design decisions have taken you to solving issues that might not exist with an alternative, more-naturally-zope-like approach.
As the question appears they should be solved and Ross asked community to help. m. P.S. It is really interesting what X-Spam-Status this message will get ;) the one of Gary had 3.2 :) Maybe there is a sense to lower threshold from 5.0 to 3.0 ;) -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav@zope.net.ua <mailto:myroslav@zope.net.ua> cell: +380 50.3174578
Myroslav Opyr wrote:
as this one is dedicated to next-generation product enhancement as opposed to peer user assistance.
Reason rejected... Question was technical and was dedicated to zope-dev list.
Let me rephrase ;-) This list is for development _of_ not _with_ Zope. Ross' question was about the development of an application, which is prettymuch zope@zope.org territory... cheers, Chris
Chris Withers wrote:
Myroslav Opyr wrote:
as this one is dedicated to next-generation product enhancement as opposed to peer user assistance. Reason rejected... Question was technical and was dedicated to zope-dev list.
Let me rephrase ;-)
This list is for development _of_ not _with_ Zope. Ross' question was about the development of an application, which is prettymuch zope@zope.org territory...
Ok, you are right. But Zope development moved into Zope3-dev list mainly and this list was used for Zope 2.6 which should be community driven release. Thus a lot of Zope Product Developers (ZPD ;) and Zope Coders (ZC ;) gathered here. The question was tricky one and no other list could help better but zope-dev... And discussion regarding the subject would be useful for Zope core as well as for product developers because Refresh is widely used by ZPD and ZC. I, personally, also have different issues regarding Refresh, I'm searching for workarounds and hope this discussion will also spill the light on my case too. m. P.S. This thread is becoming flamy... Let's continue it in private mail. Thanks. -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav@zope.net.ua <mailto:myroslav@zope.net.ua> cell: +380 50.3174578
Chris Withers <chrisw@nipltd.com> wrote:
Let me rephrase ;-)
This list is for development _of_ not _with_ Zope. Ross' question was about the development of an application, which is prettymuch zope@zope.org territory...
FWIW, I consider the zope@zope.org list to be the "newbie" list, and the zope-dev@zope.org one to be the "experimented developer" one. Very often the experimented developer has questions about the design or internals of Zope itself. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
participants (9)
-
Adrian Hungate -
Chris Withers -
Florent Guillaume -
Gary Speer -
Lennart Regebro -
Lennart Regebro -
Myroslav Opyr -
Ross Boylan -
Toby Dickenson