[Zope] Re: Zope Digest, Vol 19, Issue 24
-bhavana -
hi.bhavana at gmail.com
Mon Dec 19 01:52:04 EST 2005
hi all,
i have my ontology in mysql. i connect mysql with zope and plone. and i made
search interface also in Plone. Now i want to search my documents and
display results according to the ontology. Can anyone suggest how to move
forward for this?
thankx in advance,
bh
On 12/19/05, zope-request at zope.org <zope-request at zope.org> wrote:
>
> Send Zope mailing list submissions to
> zope at zope.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.zope.org/mailman/listinfo/zope
> or, via email, send a message with subject or body 'help' to
> zope-request at zope.org
>
> You can reach the person managing the list at
> zope-owner at zope.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Zope digest..."
>
>
> Today's Topics:
>
> 1. Re: Zope Persistence (was: XML-RPC within ZOPE) (Lennart Regebro)
> 2. Re: Zope Persistence (was: XML-RPC within ZOPE) (Lennart Regebro)
> 3. zyncer 0.7.0? (David H)
> 4. Re: zyncer 0.7.0? (David H)
> 5. RE: zopectl or runzope just won't start zope (Russell Winter)
> 6. Re: Zope Persistence (was: XML-RPC within ZOPE) (Jan-Ole Esleben)
> 7. Re: zope-2.9 r40780 make install doesn't finish, files
> missing from bin (Sascha Ottolski)
> 8. Re: Zope Persistence (was: XML-RPC within ZOPE) (Lennart Regebro)
> 9. Re: Zope Persistence (was: XML-RPC within ZOPE) (Jan-Ole Esleben)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Dec 2005 01:30:39 +0100
> From: Lennart Regebro <regebro at gmail.com>
> Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
> To: Jan-Ole Esleben <esleben at gmail.com>
> Cc: zope user list <zope at zope.org>
> Message-ID:
> <319e029f0512171630s3921efdaseb54be4c12281480 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 12/17/05, Jan-Ole Esleben <esleben at gmail.com> wrote:
> > To simplify, in ZOPE, for any given product, during a
> > transaction the product is effectively locked.
>
> This statement is incorrect.
>
> > So if I have, say, a
> > list field that contains some data and a dictionary field that
> > contains some other data, and the "internal" call changes the dict
> > while the original call changes the list, that breaks the transaction,
> > while in usual situation in a database, nothing would break.
>
> If you use all non-persistent aware dicts and lists, yes. Using only
> dicts and lists is suboptimal in most OO-languages, and that goes for
> Python too. It is correct that with Zope, the negative impact of that
> type of pre'ogramming-style is increased. This is however simply
> solved by not doing that type of suboptimization, and instead using
> persistant-aware objects.
>
> > No. It does happen, and it _did_ happen in my original problem. Zope
> > doesn't even care if anything actually changes, it just considers an
> > object changed that set self._p_changed=1.
>
> No, se above.
>
> > > You just said "different sets of data". That reasonably must mean
> > > different objects, unless you envision having huge objects with only
> > > marginally connected sets of data all stored as attributes. And then
> > > you have other problems. :-)
> >
> > No. An object usually binds together different sets of data (as in the
> > above example - it has several fields, and that is true for almost any
> > given object).
>
> Yes. You said "different sets of data". That reasonably means
> different objects. If it doesn't, yuo need to take a long hard look at
> your object hierarchy.
>
> > What you are saying is "don't program the ZOPE way",
>
> No, in fact, I'm saying "program the Zope way", and I am beginning to
> suspect that the problem is that you are not.
>
> > and it would eventually lead to the conclusion that your product
> > classes should not have any persistent data, which is the conclusion I
> > have come to.
>
> Then you didn't read what I said.
>
> > > > That's my whole point. I think it is a very
> > > > significant point nonetheless, because this is just an extreme case
> of
> > > > what happens when you couple data and programs, and persistent
> classes
> > > > are just that: application data inside program code.
>
> > > Eh, no they aren't.
> >
> > Please don't just claim stuff.
>
> You do.
>
> > ZOPE has persistent classes. Persistent
> > classes store data that in ordinary programs would not survive as
> > long.
>
> Not unless you tell them to. If you don't want the data stored, then
> do not set it as an attribute on a persistent object.
>
> > In ordinary systems, you would have to find a way to store the
> > data and retrieve it, thus having a model that isn't implicit and
> > entangled with your code.
>
> What is implicit with it?
>
> > Of course, you could do the same in ZOPE,
> > but I addressed that above, and you could mess up ordinary code, but I
> > think we're agreed that it is not something you should aim for (and I
> > think I have made it clear why I do not believe it's as easy to mess
> > up generic Python code in this way)
>
> Well, sorry, it's not clear for me.
>
>
> To summarize:
>
> If you have two different processes changing the same set of data, you
> will get confllict errors. You claim that you will not, but this is
> false.
>
> You claim that you can't control what a persistent class store. That is
> false.
>
> You claim that the whole Zope product gets locked, that is false. It's
> on a object-basis, not a product basis.
>
> You claim that things get locked that shouldn't be locked in Zope. It
> is not clear to me why you say that.
>
> --
> Lennart Regebro, Nuxeo http://www.nuxeo.com/
> CPS Content Management http://www.cps-project.org/
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Dec 2005 01:35:46 +0100
> From: Lennart Regebro <regebro at gmail.com>
> Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
> To: Jan-Ole Esleben <esleben at gmail.com>
> Cc: Tino Wildenhain <tino at wildenhain.de>, zope user list
> <zope at zope.org>
> Message-ID:
> <319e029f0512171635n1bc72607ie198b44fbd8128e8 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 12/17/05, Jan-Ole Esleben <esleben at gmail.com> wrote:
> > You should be able to
> > design stuff incrementally with a little experimentation along the way
> > without constantly impending danger of it all crashing down on you.
>
> I don't undertand why you say that this isn't possible in Zope.
>
> > That's how Python works, and RoR etc. In ZOPE, we're back to the
> > temptation to "just stuff a bunch of data into my object". And it's
> > not even obvious that this is a problem, because everything is so
> > tightly interdependent. It's exactly what Python usually avoids
> > ("explicit is better than implicit").
>
> I agree that there is too much implicitness in Zope 2. I don't agree
> that persistance is a part of that. It isn't implicit at all. Maybe
> it's not easy to understand, but it isn't particularily implicit, and
> neither is it uncontrollable, as you seem to say.
>
> --
> Lennart Regebro, Nuxeo http://www.nuxeo.com/
> CPS Content Management http://www.cps-project.org/
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 17 Dec 2005 18:13:18 -0800
> From: David H <bluepaul at earthlink.net>
> Subject: [Zope] zyncer 0.7.0?
> To: zope user list <zope at zope.org>
> Message-ID: <43A4C5BE.60402 at earthlink.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi List,
>
> I downloaded zsyncer-0.7.0 and am having problems. Its not working
> for me and it no longer displays prompts for destination password and
> user name when clicking its <edit> tab. Anyone else seeing this?
>
> More importantly, as a fall-back is there a version (0.6.1?) others
> recommend?
>
> All best,
> David
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 17 Dec 2005 19:58:01 -0800
> From: David H <bluepaul at earthlink.net>
> Subject: Re: [Zope] zyncer 0.7.0?
> To: Alan Milligan <alan at balclutha.org>
> Cc: zope user list <zope at zope.org>
> Message-ID: <43A4DE49.6090301 at earthlink.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Alan Milligan wrote:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >David H wrote:
> >
> >
> >>Hi List,
> >>
> >>I downloaded zsyncer-0.7.0 and am having problems. Its not working
> >>for me and it no longer displays prompts for destination password and
> >>user name when clicking its <edit> tab. Anyone else seeing this?
> >>
> >>
> >>
> >You need to use extended url auth syntax:
> >http://username:password@your.domain.com/bla ...
> >
> >This is because we can have multiple targets all with different
> >passwords ...
> >
> >Alan
> >
> >
> >
> Alan,
>
> Thanks for your response. Apparently my <zope-instance>bin/zopectl stop
> / restart sequence was not working on my remote (zettai) instance.
> I had to do a shutdown from the control panel and *then* a bin/zopectl
> start worked just fine - and zyncer came up as it should. The install of
> zsyncer 0.7.0 on my *localr* system was fine - hence the disconnect in
> what I was seeing ...
>
> David
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.zope.org/pipermail/zope/attachments/20051217/1a59bae7/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Sun, 18 Dec 2005 22:54:05 +1100
> From: "Russell Winter" <rwinter at r2solutions.com.au>
> Subject: RE: [Zope] zopectl or runzope just won't start zope
> To: "'Qass'" <qassair at gmail.com>, <zope at zope.org>
> Message-ID: <00ed01c603c9$bf38d340$1e0a0a0a at WinterRGM>
> Content-Type: text/plain; charset="us-ascii"
>
> Not that I am any real guru on this, however, I am still learning myself,
> my
> 2c worth....
>
> The error output suggests that Zope is installed on a network share of
> some
> sort ...
>
> File
> "/network/share/home/sra/Zope-2.8.4-final
> /lib/python/Zope2/Startup/__init__.
> py",
> line 24, in ?
>
> Are the permissions or effective user correct for the appropriate
> filesystems and files.?
>
> If you installed the binaries as root, but are running Zope as another
> user,
> you will need to assign either that effective user to the root group, or
> potentially less hazardous, security wise, assign the correct effective
> user
> group rights to the filesystem area, including the network share.
>
> If you have not assigned an effective user, or ran mkzopeinstance as root,
> then you may see these type of errors when trying to run Zope as another
> user without the correct permissions. Or when running as root, when
> effective user permissions are assigned elsewhere.
>
> Russ
>
> -----Original Message-----
> From: zope-bounces at zope.org [mailto:zope-bounces at zope.org] On Behalf Of
> Qass
> Sent: Thursday, December 15, 2005 5:13 AM
> To: zope at zope.org
> Subject: [Zope] zopectl or runzope just won't start zope
>
> Hi:
>
> I'm new to zope and yesterday installed zope 2.8.4 on a linux system
> running
> python 2.3.5 Having followed installation instructions I got to the point
> of
> 'zopectl start' and got the following error message while trying both
> 'runzope' and 'zopectl'.
>
> I've tried installing different versions of Zope and get the same error
> (error absent with Zope 3). At one point, Zope did start (I moved it to a
> different port) but when I tried installing Plone in the Products
> directory
> of the zope instance, the 'Plone Site' did not show up in the drop down
> menu
> on the right hand side of the ZMI. Which is why I decided to reinstall and
> have been getting errors since. I haven't messed around with the Python
> installation at all.
>
> In this latest install I ran 'make instance' intead of 'make install'
> just to see if I would get the same error as I did yesterday when I had an
> instance of Zope running and I did.
>
> Any help in trying to fix this would be highly appreciated. I've tried
> changing PYTHONPATH in the zopectl file but that just leads to more and
> more
> errors.
>
> Traceback (most recent call last):
> File "/blah//Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 56,
> in ?
> run()
> File "/blah/Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 17, in
> run
> import Zope2.Startup
> File "/blah/Zope-2.8.4-final/lib/python/Zope2/__init__.py", line 60, in ?
> from Zope2.Startup.run import configure
> File
> "/network/share/home/sra/Zope-2.8.4-final
> /lib/python/Zope2/Startup/__init__.
> py",
> line 24, in ?
> import ZConfig
> File "/blah/Zope-2.8.4-final/lib/python/ZConfig/__init__.py", line 21, in
> ?
> from ZConfig.loader import loadConfig, loadConfigFile
> File "/blah/Zope-2.8.4-final/lib/python/ZConfig/loader.py", line 23, in ?
> import ZConfig.datatypes
> File "/blah/Zope-2.8.4-final/lib/python/ZConfig/datatypes.py", line 19, in
> ?
> import datetime
> File "/blah/Zope-2.8.4-final/lib/python/DateTime/__init__.py", line 13, in
> ?
> from DateTime import DateTime
> File "/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in
> ?
> from datetime import datetime
> File "/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in
> ?
> from datetime import datetime
> ImportError: cannot import name datetime
>
> Thank you very much for your help.
>
> Qass
> _______________________________________________
> Zope maillist - Zope at 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 )
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 18 Dec 2005 13:45:48 +0100
> From: Jan-Ole Esleben <esleben at gmail.com>
> Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
> To: Lennart Regebro <regebro at gmail.com>
> Cc: zope user list <zope at zope.org>
> Message-ID: <3756d9750512180445u1c47cdccl at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > > To simplify, in ZOPE, for any given product, during a
> > > transaction the product is effectively locked.
> > This statement is incorrect.
>
> You're right. It should be "during any transaction where there are
> potential changes to the object". And I agree, it's actually a lot
> more complicated than I'd thouht at first. What I describe can happen,
> but it happens under rather magical circumstances. I have an example
> where it actually happens; this is code from a product that is
> instantiated twice, one of those instances called TPCDest, the other
> TestPChanged; the method called directly is "TestPChanged.test()":
>
> security.declareProtected("Use TestPChanged", "test_internal")
> def test_internal(self, args=None, args2=None):
> "Called by test via XML-RPC"
> if args2:
> self.a.append(1)
> self._p_changed = 1
> if not args:
> import xmlrpclib
> s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
> allow_none=True)
> s.TestPChanged.test_internal(1)
> return self.a
>
> security.declareProtected("Use TestPChanged", "test")
> def test(self, args2=None):
> "Called directly via ZOPE"
> if args2:
> self.a.append(1)
> self._p_changed = 1
> import xmlrpclib
> s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
> allow_none=True)
> return s.TPCDest.test_internal()
>
> Zope obviously looks at the code, because if you remove the "if args2"
> (which is _never_ true), then a ConflictError happens.
>
> Maybe I'm stupid, but could someone point out _where_ exactly I am?
>
> > > No. It does happen, and it _did_ happen in my original problem. Zope
> > > doesn't even care if anything actually changes, it just considers an
> > > object changed that set self._p_changed=1.
> > No, se above.
>
> You're right that it doesn't always, but see my example.
>
> > Yes. You said "different sets of data". That reasonably means
> > different objects. If it doesn't, yuo need to take a long hard look at
> > your object hierarchy.
>
> Simply not true. What if I have a field titles (that is a hash of
> titles to Book objects)
> and a field comments (that is an array of comments on the library)? Is
> that so obviously
> not a sane example?
>
> > > > > That's my whole point. I think it is a very
> > > > > significant point nonetheless, because this is just an extreme
> case of
> > > > > what happens when you couple data and programs, and persistent
> classes
> > > > > are just that: application data inside program code.
> > > > Eh, no they aren't.
> > > Please don't just claim stuff.
> > You do.
>
> I don't. I at least try to give reasons wherever I make a statement
> that could be challenged.
>
> > > In ordinary systems, you would have to find a way to store the
> > > data and retrieve it, thus having a model that isn't implicit and
> > > entangled with your code.
> > What is implicit with it?
>
> See the example for some major implicitness. It's also implicit
> because you have no control over what a transaction considers a
> tainted object. (You have no real control over the transaction).
>
> > If you have two different processes changing the same set of data, you
> > will get confllict errors. You claim that you will not, but this is
> > false.
>
> I am explicitly talking about changing different sets of data within
> the same object. You noted that above yourself.
>
> > You claim that you can't control what a persistent class store. That is
> false.
>
> I don't. I say that if I want to avoid such problems as I describe
> altogether, I cannot store anything in a persistent class and thus
> lose most of what makes ZOPE so interesting.
>
> > You claim that the whole Zope product gets locked, that is false. It's
> > on a object-basis, not a product basis.
>
> I never said that, or at least I didn't mean it. If it sounded like
> that, I apologize (maybe I used Product metonymically for instance
> somewhere, which would not be a good idea, I agree).
>
> > You claim that things get locked that shouldn't be locked in Zope. It
> > is not clear to me why you say that.
>
> See the example.
>
> Ole
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 18 Dec 2005 15:32:40 +0100
> From: Sascha Ottolski <sascha.ottolski at gallileus.de>
> Subject: Re: [Zope] zope-2.9 r40780 make install doesn't
> finish, files
> missing from bin
> To: zope at zope.org
> Cc: Jeff Kowalczyk <jtk at yahoo.com>
> Message-ID: <200512181532.41103.sascha.ottolski at gallileus.de>
> Content-Type: text/plain; charset="iso-8859-15"
>
> Am Mittwoch, 14. Dezember 2005 21:11 schrieb Jeff Kowalczyk:
> > I'm having some trouble with the 'make install' stage of Zope-2.9 svn.
>
> Hi Jeff,
>
> just stumbled over the same problem. By chance, we figured out how to do
> it:
> you need to "make sdist" beforehand, which creates a tarball for you,
> which
> in turn you must use to perform the regular install. "make sdist" needs
> "zpkg", which is found at http://svn.zope.org/zpkgtools/; don't know how
> to
> install it, so we just changed the path in the makefile to point to the
> right
> place, in our case
>
> ZPKG=/mnt/source/svn/svn.zope.org/zpkgtools/bin/zpkg
>
>
> Hope that helps,
>
> Sascha
>
> --
> Gallileus - the power of knowledge
>
> Gallileus GmbH http://www.gallileus.info/
>
> Pintschstra�e 16 fon +49-(0)30-41 93 43 43
> 10249 Berlin fax +49-(0)30-41 93 43 45
> Germany
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 18 Dec 2005 17:00:22 +0100
> From: Lennart Regebro <regebro at gmail.com>
> Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
> To: Jan-Ole Esleben <esleben at gmail.com>
> Cc: zope user list <zope at zope.org>
> Message-ID:
> <319e029f0512180800gb6d7fa8hac21ad01c8d3c2a0 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 12/18/05, Jan-Ole Esleben <esleben at gmail.com> wrote:
> > > > To simplify, in ZOPE, for any given product, during a
> > > > transaction the product is effectively locked.
> > > This statement is incorrect.
> >
> > You're right. It should be "during any transaction where there are
> > potential changes to the object".
>
> No, this statement is still correct. Replace "product" with "object"
> and you are right.
>
> > And I agree, it's actually a lot more complicated than I'd thouht at
> first.
>
> Or simpler. ;-)
>
> > but it happens under rather magical circumstances. I have an example
> > where it actually happens; this is code from a product that is
> > instantiated twice, one of those instances called TPCDest, the other
> > TestPChanged; the method called directly is "TestPChanged.test()":
> >
> > security.declareProtected("Use TestPChanged", "test_internal")
> > def test_internal(self, args=None, args2=None):
> > "Called by test via XML-RPC"
> > if args2:
> > self.a.append(1)
> > self._p_changed = 1
> > if not args:
> > import xmlrpclib
> > s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/
> ",
> > allow_none=True)
> > s.TestPChanged.test_internal(1)
> > return self.a
> >
> > security.declareProtected("Use TestPChanged", "test")
> > def test(self, args2=None):
> > "Called directly via ZOPE"
> > if args2:
> > self.a.append(1)
> > self._p_changed = 1
> > import xmlrpclib
> > s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
> > allow_none=True)
> > return s.TPCDest.test_internal()
> >
> > Zope obviously looks at the code, because if you remove the "if args2"
> > (which is _never_ true), then a ConflictError happens.
> >
> > Maybe I'm stupid, but could someone point out _where_ exactly I am?
>
> I don't understand the question. I would like to point out that you
> set self._p_changed even when you don't change anything. :-)
>
> It seems to me that you say that if you process calls test and another
> calls test_internal, you get a conflict error. This is correct, and as
> noted before, that code would create a conflict in any type of
> environment. If you have two processes trying to modify the same
> dataset, which is what your example seems to do, then you get a
> conflict.
>
> What you claim, is that if you have two processes in Zope change two
> different datasets, you get a conflict. That statement is still false.
>
> > > Yes. You said "different sets of data". That reasonably means
> > > different objects. If it doesn't, yuo need to take a long hard look at
> > > your object hierarchy.
> >
> > Simply not true. What if I have a field titles (that is a hash of
> > titles to Book objects)
> > and a field comments (that is an array of comments on the library)? Is
> > that so obviously
> > not a sane example?
>
> Yes, sorry, having non-persistent aware dictionaries or arrays, and
> then complaining that you have problems with persitency...
>
> > > > In ordinary systems, you would have to find a way to store the
> > > > data and retrieve it, thus having a model that isn't implicit and
> > > > entangled with your code.
> > >
> > > What is implicit with it?
> >
> > See the example for some major implicitness.
>
> What is implicit with it?
>
> > It's also implicit
> > because you have no control over what a transaction considers a
> > tainted object. (You have no real control over the transaction).
>
> Thats still not true.
>
> > I am explicitly talking about changing different sets of data within
> > the same object. You noted that above yourself.
>
> Then these different sets should be different objects, and the object
> should be an object container: Problem solved.
>
> > > You claim that you can't control what a persistent class store. That
> is false.
> >
> > I don't. I say that if I want to avoid such problems as I describe
> > altogether, I cannot store anything in a persistent class and thus
> > lose most of what makes ZOPE so interesting.
>
> This is still not correct.
>
> > > You claim that things get locked that shouldn't be locked in Zope. It
> > > is not clear to me why you say that.
> >
> > See the example.
>
> I don't see how the example examplifies this.
>
>
> It is obvious to me that you have misunderstood something. I don't
> know what yet, though.
>
> --
> Lennart Regebro, Nuxeo http://www.nuxeo.com/
> CPS Content Management http://www.cps-project.org/
>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 18 Dec 2005 17:25:15 +0100
> From: Jan-Ole Esleben <esleben at gmail.com>
> Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
> To: Lennart Regebro <regebro at gmail.com>
> Cc: zope user list <zope at zope.org>
> Message-ID: <3756d9750512180825u35fd6eb9o at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > > but it happens under rather magical circumstances.
>
> That's my problem. Can you, from the ZOPE documentation, predict that
> the example below will cause a ConflictError? It doesn't if you alter
> it only slightly! Please try!
>
> > > security.declareProtected("Use TestPChanged", "test_internal")
> > > def test_internal(self, args=None, args2=None):
> > > "Called by test via XML-RPC"
> > > if args2:
> > > self.a.append(1)
> > > self._p_changed = 1
> > > if not args:
> > > import xmlrpclib
> > > s = xmlrpclib.ServerProxy("
> http://USER:PASSWORD@localhost:8080/",
> > > allow_none=True)
> > > s.TestPChanged.test_internal(1)
> > > return self.a
> > >
> > > security.declareProtected("Use TestPChanged", "test")
> > > def test(self, args2=None):
> > > "Called directly via ZOPE"
> > > if args2:
> > > self.a.append(1)
> > > self._p_changed = 1
> > > import xmlrpclib
> > > s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
> > > allow_none=True)
> > > return s.TPCDest.test_internal()
>
> > I don't understand the question. I would like to point out that you
> > set self._p_changed even when you don't change anything. :-)
>
> I know. This is just example code. Just imagine that both methods
> change completely unrelated sets of data in addition to not changing
> self.a.
>
> > It seems to me that you say that if you process calls test and another
> > calls test_internal, you get a conflict error.
>
> It doesn't really in most cases. And of course I can see now where it
> does in this instance, but this is based on Zope looking at the code,
> determining that self.a is changed before the _p_changed, and marking
> the object tainted because of that.
>
> > This is correct, and as
> > noted before, that code would create a conflict in any type of
> > environment. If you have two processes trying to modify the same
> > dataset, which is what your example seems to do, then you get a
> > conflict.
> > What you claim, is that if you have two processes in Zope change two
> > different datasets, you get a conflict. That statement is still false.
>
> Actually, I don't think we're getting anywhere with this same
> dataset/different dataset distinction. It wouldn't happen in a
> database using application because there would be no transaction for
> "self.a". You see, nothing happens to it, so why would there be one?
> This only happens when you mix your data with your code and have
> implicit transactions handled by the server.
>
> > Yes, sorry, having non-persistent aware dictionaries or arrays, and
> > then complaining that you have problems with persitency...
>
> But that's part of my point: I need to go out of my way to circumvent
> Python, and I need to be really careful, because using dicts and lists
> might still work. Nothing is enforced, and where it breaks is hard to
> predict.
>
> > > See the example for some major implicitness.
> > What is implicit with it?
>
> I explained this above. Transaction handling in Zope (someone else
> pointed that out in this thread), Zope looking at the code to
> determine that self.a has changed (which isn't really documented
> anywhere obvious).
>
> > > > You claim that things get locked that shouldn't be locked in Zope.
> It
> > > > is not clear to me why you say that.
> > > See the example.
> > I don't see how the example examplifies this.
>
> I have tried to make it a little clearer in this message.
>
> > It is obvious to me that you have misunderstood something. I don't
> > know what yet, though.
>
> I think we might be misunderstanding each other because we both place
> different value on implicitness and explicit design of data inside
> code. I am mostly talking about what is, pragmatically, good
> programming and a supportive environment.
>
> Ole
>
>
> ------------------------------
>
> _______________________________________________
> Zope maillist - Zope at zope.org
>
>
>
> End of Zope Digest, Vol 19, Issue 24
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope/attachments/20051219/8e3e197b/attachment-0001.htm
More information about the Zope
mailing list