Is there any reason why an object cannot be contained in more than one Folder in the ZODB? Apparently what I'm talking about is very similar to hard linking in UNIX... I can't think of any reasons why this would be bad but I can't think how to implement an 'Add hard link to this object' function... Ideas/comments? cheers, Chris
On Mon, 17 Jul 2000, Chris Withers wrote:
Is there any reason why an object cannot be contained in more than one Folder in the ZODB?
Apparently what I'm talking about is very similar to hard linking in UNIX...
Hardlinks are prohibited on directories; and 5 minutes ago you said all objects are foldersih :) Hardlinks are prohibited on directories because it'd cause infinite loops on traversing. Oleg. (All opinions are mine and not of my employer) ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
Hardlinks are prohibited on directories; and 5 minutes ago you said all objects are foldersih :)
I'm not sure if my statement applies in this situation... ;-)
Hardlinks are prohibited on directories because it'd cause infinite loops on traversing.
Hmm, would Python catch those already? Obviously care would need to be taken and it might be possible to build a loop checker into whatever creates the hard links... cheers, Chris
Chris Withers wrote:
Oleg Broytmann wrote:
Hardlinks are prohibited on directories; and 5 minutes ago you said all objects are foldersih :)
I'm not sure if my statement applies in this situation... ;-)
Hardlinks are prohibited on directories because it'd cause infinite loops on traversing.
Hmm, would Python catch those already?
Obviously care would need to be taken and it might be possible to build a loop checker into whatever creates the hard links...
This could be part of a "visitor" interface I've been pondering in the back of my mind. It would be capable of traversing, performing an arbitrary function, and never falling into a recursive trap. class ObjectManager: ... def visit(self, func, visited=()): func(self) for id in self.objectIds(): ob = self._getOb(id) if hasattr(ob, 'visit') and ob not in visited: ob.visit(func, (ob,) + visited) Shane
Shane Hathaway wrote:
This could be part of a "visitor" interface I've been pondering in the back of my mind. It would be capable of traversing, performing an arbitrary function, and never falling into a recursive trap.
Cool :-) Let me know when it's available :-) Can you see any weirdities that might occur from having an object as an attribute of more than one object manager / folder? Chris PS: Do you know the answer to my &dtml.url-; question I asked earlier?
Chris Withers wrote:
Shane Hathaway wrote:
This could be part of a "visitor" interface I've been pondering in the back of my mind. It would be capable of traversing, performing an arbitrary function, and never falling into a recursive trap.
Cool :-)
Let me know when it's available :-)
Can you see any weirdities that might occur from having an object as an attribute of more than one object manager / folder?
The recursion problem, for one. Also, if you change the object in one place, it will also get changed in the other, which may not be the expected behavior. You could also do soft links like this (I bet this actually works :-) ): class SoftLink (SimpleItem): def __init__(self, path): self.path = path def __of__(self, parent): ob = self.restrictedTraverse(self.path) return getattr(ob, 'aq_base', ob).__of__(parent) ... but once again, changes made in one place would cause changes in the other. And then there are security considerations: how should the security behave if two users with different roles want to access/change the object?
PS: Do you know the answer to my &dtml.url-; question I asked earlier?
I couldn't find your question. :-( Shane
Shane Hathaway wrote:
Can you see any weirdities that might occur from having an object as an attribute of more than one object manager / folder?
The recursion problem, for one.
Hmmm, how much of Zope would need changing to use the visitor interface?
Also, if you change the object in one place, it will also get changed in the other, which may not be the expected behavior.
Nope, that's exactly the desired and expected behaviour :-) What about Zope's deleting machinery? The desired effect is similar to a refcount, the object only gets deleted when all references to it have been deleted...
You could also do soft links like this (I bet this actually works :-) ):
class SoftLink (SimpleItem): def __init__(self, path): self.path = path
def __of__(self, parent): ob = self.restrictedTraverse(self.path) return getattr(ob, 'aq_base', ob).__of__(parent)
... but once again, changes made in one place would cause changes in the other. And then there are security considerations: how should the security behave if two users with different roles want to access/change the object?
How does it work in Unix? (that seems to be a good baseline :-)
PS: Do you know the answer to my &dtml.url-; question I asked earlier?
I couldn't find your question. :-(
Urg.. it was on zope@zope.org, sorry :-S Basically, can you do &dtml.url-/folder/object/method; yet? cheers, Chris
On Mon, 17 Jul 2000, Chris Withers wrote:
How does it work in Unix? (that seems to be a good baseline :-)
On UNIX symlink is not a link - it is a text file, that contains a name of resource. The name could points to nowhere, or to resource, even to other symlink... Oleg. (All opinions are mine and not of my employer) ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
On Mon, 17 Jul 2000, Chris Withers wrote:
How does it work in Unix? (that seems to be a good baseline :-)
On UNIX symlink is not a link - it is a text file, that contains a name of resource. The name could points to nowhere, or to resource, even to other symlink...
So, it is up to the operating system to interpret the soft link and redirect accordingly. Shane's soft-link code looks like the object-oriented equivalent; a bit of text that knows where to redirect callers to. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
participants (4)
-
Chris Withers -
Oleg Broytmann -
Shane Hathaway -
Steve Alexander