[Zope-dev] Test(Persistent) failing with AttributeError: __hash__
In the following code either I am using dictionaries wrong or I'm
missing something with ExtensionClass in general. Can someone explain
the best way for me to map from one instance to another?
I have tried searching Zope and Python mailing lists and resources for
an answer to this question but have become confused by different
conflicting messages. On the one hand I have heard that dictionary keys
are supposed to be immutable. On the other, I've heard that
dictionaries are used to simulate (key is object, value is ignored) some
aspects of sets. Which is correct?
What I really want is to be able to map a Persistent object to a string.
Thanks for any help.
John Heintz
import ZODB
from Persistence import Persistent
class Test1:
pass
class Test2(Persistent):
pass
dict = {}
t1 = Test1()
t2 = Test2()
try:
dict[t1] = 1
except:
print "Using instance of Test1 as key failed!"
try:
dict[t2] = 2
except:
print "Using instance of Test2(Persistent) as key failed!"
--
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Please help - Persistent dictionary keys
Can someone please explain the best way for me to map from one instance
to another?
In the following code either:
(1) I am using dictionaries wrong, or
(2) I'm missing something with ExtensionClass in general.
I have tried searching Zope and Python mailing lists and resources for
an answer to this question but have become confused by different
conflicting messages. On the one hand I have heard that dictionary keys
are supposed to be immutable. On the other, I've heard that
dictionaries are used to simulate (key is object, value is ignored) some
aspects of sets. Which is correct?
What I really want is to be able to map a Persistent object to a string
with fast lookup.
Thanks for any help.
John Heintz
import ZODB
from Persistence import Persistent
class Test1:
pass
class Test2(Persistent):
pass
dict = {}
t1 = Test1()
t2 = Test2()
try:
dict[t1] = 1
except:
print "Using instance of Test1 as key failed!"
try:
dict[t2] = 2
except:
print "Using instance of Test2(Persistent) as key failed!"
--
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please help - Persistent dictionary keys
Thanks for the reply Martijn,
I do want the objects of Test2 class to be compared by identity, like
I'm assuming Test1 objects are.
If I have to define __cmp__ and __hash__ then I will basically be making
them up because the object in question are mutable - except for their
identity.
Why do the Python class instances naturally act as dictionary keys while
the ExtensionClass instances don't?
Thanks for the time,
John
Martijn Pieters wrote:
>
>From the Python Library Reference:
"""A dictionary's keys are almost arbitrary values. The only types of
values not acceptable as keys are values containing lists or
dictionaries or other mutable types that are compared by value rather
than by object identity."""
<...>
> So, if you want to be able to use a Persistent based object as keys to a
> dictionary, implement __cmp__ and __hash__ methods on that class:
>
> >>> import ZODB
> >>> from Persistence import Persistent
> >>> class Test1:
> ... pass
> ...
> >>> class Test2(Persistent):
> ... def __cmp__(self): return 1
> ... def __hash__(self): return 1
> ...
> >>> dict = {}
> >>> t1 = Test1()
> >>> t2 = Test2()
> >>> dict[t1] = 1
> >>> dict[t2] = 2
> >>> dict
> {: 2, <__main__.Test1 instance at 80a3e78>: 1}
> >>>
>
> --
> Martijn Pieters
> | Software Engineer mailto:[EMAIL PROTECTED]
> | Digital Creations http://www.digicool.com/
> | Creators of Zope http://www.zope.org/
> -
--
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please help - Persistent dictionary keys
Thanks for the reply Martijn,
I do want the objects of Test2 class to be compared by identity, like
I'm assuming Test1 objects are.
If I have to define __cmp__ and __hash__ then I will basically be making
them up because the object in question are mutable - except for their
identity.
Why do the Python class instances naturally act as dictionary keys while
the ExtensionClass instances don't?
Thanks for the time,
John
Martijn Pieters wrote:
>
>From the Python Library Reference:
"""A dictionary's keys are almost arbitrary values. The only types of
values not acceptable as keys are values containing lists or
dictionaries or other mutable types that are compared by value rather
than by object identity."""
<...>
> So, if you want to be able to use a Persistent based object as keys to a
> dictionary, implement __cmp__ and __hash__ methods on that class:
>
> >>> import ZODB
> >>> from Persistence import Persistent
> >>> class Test1:
> ... pass
> ...
> >>> class Test2(Persistent):
> ... def __cmp__(self): return 1
> ... def __hash__(self): return 1
> ...
> >>> dict = {}
> >>> t1 = Test1()
> >>> t2 = Test2()
> >>> dict[t1] = 1
> >>> dict[t2] = 2
> >>> dict
> {: 2, <__main__.Test1 instance at 80a3e78>: 1}
> >>>
>
> --
> Martijn Pieters
> | Software Engineer mailto:[EMAIL PROTECTED]
> | Digital Creations http://www.digicool.com/
> | Creators of Zope http://www.zope.org/
> -
--
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] New Proposal: PersistentBlob
Hi all, Yesterday I put up a new proposal on the http://dev.zope.org site that documents my vision of PersistentBlob. The main idea is the be able to mark blocks of strings (text or binary) content for storage in a file system as individual files. (Or blobs in a relation table.) The two motivations for this are keeping a ZODB FileStorage small and exposing blocks of string content to external processes (i.e. full-text indexing). Thanks for taking a look. John -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Only using ZODB, not Zope Re: New Proposal: PersistentBlob
Hi Greg, Thanks for the pointer. I briefly looked at this Product and the CVSMixin Product as well, but have one requirement that unfortunately I _didn't_ explain clearly in my proposal. I am not using Zope, only the ZODB so a Zope Product will not help me. My first goal with the proposal was to get feedback on if my idea is correct and what implementation problems could occur, i.e. transactions and file locking. My second goal is to inspire someone to implement it and merge it into the official ZODB. I think that the idea has enough merit and could be useful for a large number of applications. We might have the time and need to implement PersistentBlob ourselves, but I can't say for sure now. Thanks all, John Gregor Heine wrote: > > > Hi all, > > > > Yesterday I put up a new proposal on the http://dev.zope.org site that > > documents my vision of PersistentBlob. The main idea is the be able to > > mark blocks of strings (text or binary) content for storage in a file > > system as individual files. (Or blobs in a relation table.) > > > > The two motivations for this are keeping a ZODB FileStorage small and > > exposing blocks of string content to external processes (i.e. full-text > > indexing). > > > > Thanks for taking a look. > > John > > Hi John! > > Have you had a look at the ExtFile Product > (http://www.zope.org/Members/MacGregor/ExtFile)? > It basically does all the things you want to achive with the PersistentBlob > (i.e. storing files externally and making them accessible for external > processes), except that it's not that deeply integrated into the Zope > machinery and stores the files only in the file system and not in an RDBMS > (which nevertheless could be implemented). > > Cheers, Gregor! -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CORBA-ZODB: Is replacing global get_transaction() the only way...
globals to return the appropriate > > Transaction regardless of thread. > > It currently returns a different transaction depending on the thread. In the CORBA exposure I would never call get_transaction(). I would use the reference to a transaction from the CORBA Session object that originally open()ed a database connection. > > Again, my preference is number one. After going over the ZODB code, I > > _think_ that a Connection is always associated with one Transaction. If > > this assumption is true, then it should be safe to make the change I'm > > proposing. If not, then I need to understand why so that I can rethink > > how to solve my problem. ;-) > > > > I hope that I've made my problems and ideas for solutions clear, if not > > please let me know. > > I dunno. You'll probably be able to tell from my response. :) Only the difference between thread/Connection/transaction per request versus exposing the same cached object across multiple CORBA requests. > > Also, I think that I should be able to make the > > changes to ZODB myself within the next few week, but only if there is > > the _possibility_ of folding them back into the main Zope codebase. > > I sincerely hope that no ZODB changes are necessary. This is, in Python, the changes to Persistent that I feel would solve my problem. I think that in general this code would allow multiple thread to modify ZODB objects while still keeping the right transaction up to date. import ZODB from Persistence import Persistent class TestPersistent(Persistent): self __changed__(self): "Completely ignoring self->state from c code..." if self._p_jar: self._p_jar.transaction.register(self) and then in DB.py the open() method must add a transaction attribute to the connection before returning. I've got one more question. What happens if I: - make a connection to a database - navigate to some objects and store references to them - make some changes to these objects - call get_transaction().abort() - make some changes to the same objects (that I have references to) - call get_transaction().commit() Will everything do what I expect in this case? Thanks so much for you time, John Heintz > > Thanks for any help, > > John D. Heintz > > > > CORBA Threading description: > > CORBA defines the POA, which has two standard threading policies: > > ORB Controlled Model > > Single Threaded Model > > > > The POA is basically a controller for requests to one or more > > distributed objects, with thread policy as one of its parameters. > > > > The first threading policy means whatever the ORB gives you - single or > > multi, and you have to deal with all synchronizations. > > > > The second I consider a mis-nomer because there can be many threads, but > > only one at a time will access objects for a given POA. (This is the > > model that I perceive being used by default for ZODB object from a > > specific Connection.) > > No. Multiple threads can be accessing the same logical object. > Each thread has it's own copy (and DB connection and transaction). > > Jim > > -- > Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! > Technical Director (888) 344-4332http://www.python.org > Digital Creationshttp://www.digicool.com http://www.zope.org > > Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email > address may not be added to any commercial mail list with out my > permission. Violation of my privacy with advertising or SPAM will > result in a suit for a MINIMUM of $500 damages/incident, $1500 for > repeats. -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Significance of the ZODB split?
The Sourceforge exposure gives people like me with an itch to scratch a place to work on a publicly visible branch of ZODB for my two proposals without breaking anything or relying on patch files continually. John Heintz PS My proposals are ExplicitTransactions and PersistentBlob ;-) Michel Pelletier wrote: > On Fri, 8 Dec 2000, Robin Becker wrote: > > >> Anyone know why AM Kuchling needs to split off a Sourceforge project >> based on ZODB? > > > I don't think it's a "split", but AMK is using ZODB internally at his > job, and externally with his own projects, so I can see him wanting to > have some control over the distribution that he uses. > > Other than that, there could be other reasons, we, for example, do not > provide a mechanism for community checkin privledges, Sourceforge > does. I don't think we have a ZODB specific mailing list, sourceforge > offers this. > > That being said, I'm pretty sure we've allways kept up with Andrew's > patches and suggestions, and we'd be happy to create a mailing list. > > Andrew has also extended any developer at DC checkin privledges at the > sourceforge project; although I suspect we'll just continue to check > into our CVS and he'll "sync" with us that which he wants. I am, in > particular, barely not lazy enough to check stuff into branches, much > less whole other repositories. ;) > > >> I really liked the ZEO examples, but where's this going? > > > It's just open source. More power to him in my opinion. He's > definatly taking Zope and ZEO to new levels and audiences. > > -Michel > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Announcing ZODB-Corba code release
Here is the first release of code that exposes a ZODB database through CORBA (omniORB). The code is functioning, the docs are sparse, and it should work on your machines. ;-) I am only going to be in town for the next two days, then I will be unavailable until Jan 1. See http://www.zope.org/Members/jheintz/ZODB_CORBA_Connection to download the code. It's not perfect, but it works for me. Enjoy, John -- .. . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Bug reports, feature requests, etc. go in the ZEO Tracker: http://www.zope.org/Products/ZEO/Tracker Conversations etc. can take place in the Wiki: http://www.zope.org/Products/ZEO/Wiki Zope-ZEO maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-zeo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] How would I keep _v_* attributes from getting thrown away?
Hello all, I am using ZODB along with CORBA to expose peristent objects. Some of my objects have per-connection/session state. The clear example is file-like objects - effectively exposing persistent StringIO objects through CORBA. The issue is that I want multiple clients to be able to read() iterate over the same file-like corba objects. My initial idea is to have a _v_position attribute that is unique for each Connection cache object and maintains the correct position in the StringIO for each session. I obviously wouldn't want this to be a persistent attribute because a spurious commit would put it into the db and mess up any other users iterating through the same object from a different session. A volatile attribute, _v_position, however can be destroyed at any time with a cache cleanup via deactivate() call. How do I maintain volatile, but per connection stable, attributes on persistent objects? I thought about overriding the _p_deactivate() method, but I am also defining the __call_method__() hook and am bound by Bug 1783 that prevents this kind of thing. My thoughts on building this into cPersistent.c after looking through the code is to provide special processing to not remove some special attributes that also don't get saved into the db. Two ideas come to mind for this: 1) define _vs_* as volatile stable that is neither persisted nor clear()ed. This would slow down the deactivate() method though. 2) define _v_stable as a special volatile that doesn't go away. This would be quick processing in deactivate() and could be a dictionary to account for many stable volatile attributes. Thanks for any help, John -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Better test case for Bug 1783: Persistent __call_method__() interferes with __getstate__
Hello all,
The following is the best test case I have so far for bug 1783.
The behavior of the bug is that no CMethods from Persistent can be
called indirectly when the __call_method__ hook is present. This means
that I can't override any of __getstate__, __setstate__, _p_deactivate.
#!/usr/bin/python
import ZODB
from Persistence import Persistent
class P(Persistent):
def __call_method__(self, meth, methArgs, methKW={}):
return apply(meth, methArgs, methKW)
p = P()
p.__getstate__()
#This throws exception!
Persistent.__getstate__(p)
TypeError: function requires exactly 0 arguments; 1 given
--
. . . . . . . . . . . . . . . . . . . . . . . .
John D. Heintz | Senior Engineer
1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]
w w w . d a t a c h a n n e l . c o m
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How would I keep _v_* attributes from getting thrown away?
Thanks for the warning Dieter, but I'm managing threads/connections/sessions/POAs and a few other things already to expose ZODB objects through CORBA sessions. I wanted the _v_* attributes to live for the life of the DB Connections. Last night I found a fix for the bug that prevented me from overriding the _p_deactivate() method on Persistent objects, so I think that I will just do this: class ... def _p_deactivate(self): temp_position = self._v_position Persistent._p_deactivate(self) self._v_position = temp_position Thanks for the help though. John Dieter Maurer wrote: > John D. Heintz writes: > > I am using ZODB along with CORBA to expose peristent objects. Some of > > my objects have per-connection/session state. > > ... > > My initial idea is to have a _v_position attribute ... > Using "_v_" attributes for session state is a very bad idea. > They are thread(!) local and not session local. > This means, if a following request of your user (in the same session) > happens to get assigned a different thread, it will read > and update a different position. Chaos is garanteed (though you > will see it only, if your site is loaded). > > Use a session product (-> zope.org) for session data. > > > Dieter > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANNOUNCE: Zope 2.3.0 beta 3 released - Plea for bug #1884
Zope-maintainers, Please evaluate the patch in bug #1884. There is an ExtensionClass.c bug in CMethod_call that prevents calling unbound super-class methods when the __call_method__ hook exists. http://classic.zope.org:8080/Collector/1884/view thanks, John Brian Lloyd wrote: > Hi all, > > Zope 2.3.0 beta 3 is now available. You can download it > from Zope.org: > > http://www.zope.org/Products/Zope/2.3.0b3/ > > This beta contains fixes for various issues reported to > date in the beta cycle, and some older Collector bugs. > Barring any major unforseen problems, this will be the > last 2.3 beta release. > > For more information on what is new in this release, see the > CHANGES.txt and HISTORY.txt files for the release: > > - http://www.zope.org/Products/Zope/2.3.0b3/CHANGES.txt > > - http://www.zope.org/Products/Zope/2.3.0b3/HISTORY.txt > > > > > Brian Lloyd[EMAIL PROTECTED] > Software Engineer 540.371.6909 > Digital Creations http://www.digicool.com > > > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?
Wow, it's fun to hear people talking about Catalysis! Catalysis is an analysis and design methodology that focuses on components and frameworks. It stresses being able to specify component interactions with invariants, pre/post conditions, and supporting graphics. The book, "Objects, Components, and Frameworks with UML" by Desmond D'Souza and Alan Wills is no light read, but well worth it. Composing multiple frameworks together with package substitutions is really cool. ;-) We are actually combining the analysis precision from Catalysis with the code focus from XP and having really good success. John "who worked for Desmond in past life" Heintz Johan Carlsson wrote: >> ... >> When you're thinking about a system, it is often helpful to think about >> just a part of the system rather than the system as a whole. To do this, >> you define a limited "scope" around a particular subsystem. >> In this case, an Actor represents the role something from outside your >> subsystem plays when interacting with something inside your subsystem. >> >> The "something" can be an object, a person, a separate computer system, >> a corporation... >> > > > Thanks Steve, > You cleared up my confusion. > > >>> How should I look at roles in ZPatterns? >> >> This is all standard object-oriented stuff, and is not specific to ZPatterns. >> Get the Coad book, read it, and things should get clearer :-) > > > It's on my ToReadList :-) > > > >> Also, the Catalysis method puts an emphasis on defining interactions and >> collaborations between objects in terms of roles. You might want to take >> a look at that. > > > Is Catalysis method a pattern in Coads book? > > Regards, > Johan Carlsson > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Storing part of an object on the file system
Andy, I'm just checking an assumption that I'm making about the Ext* Products: They do no work out of the box with ZEO, right? That is, they would require some sort of shared network drive for all ZEO clients to functions correctly. Thanks, John Andy McKay wrote: > Actually just follow up I realised I never told you how I solved this > problem. I compacted all data types into File, Image or DTML Document. Since > I had ExtFile and ExtImage I chopped those into one class called it > ExtThing, and the wrote classes off it. ExtFile and ExtImage I cut and > pasted (not complete) for the most part. > > Then I wrote a class that called ExtHTML that is a DTML Document that > overrides the munge() and read() read functions. Instead I passed those onto > ExtThing. And there you go a DTML Document that has the main body stored on > the local file system. > > Thanks McGregor. > -- > Andy McKay. > > > - Original Message - > From: "Andy McKay" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, February 08, 2001 4:15 PM > Subject: [Zope-dev] Storing part of an object on the file system > > > >> Ok whack idea #34... Well sort of, the idea was sparked by ExtFile (yes > > its > >> all his fault honest). We want to have files on the file system for many >> reasons which I won't go into now, just take it for granted. But we also >> want some of the objects information to be in the standard data.fs, so we >> can catalog it use acquisition provide a simple interface to it and so on. >> So far you are saying thats ExtFile and you are right. >> >> But we want to extend it to any object anywhere, instead of storing the > > data > >> attribute in the object and pickling it in the ZODB I want to be able to >> store the data attribute on the file system. This gives us loads of >> advantages we also thought this would be extremely useful to other people. >> We've bounced around ideas on how to do this and here the only two so far: >> >> -we could overload the data attribute with a class that on Pickling > > into > >> the ZODB instead writes it on to the filesystem... >> -we could in the ZODB put a hack to say if pickling something with so >> and so attribute do this instead... >> >> I feel like this something I should just not be doing, but it would be > > great > >> if I could get it work... >> >> -- >> Andy McKay. >> >> >> >> >> ___ >> Zope-Dev maillist - [EMAIL PROTECTED] >> http://lists.zope.org/mailman/listinfo/zope-dev >> ** No cross posts or HTML encoding! ** >> (Related lists - >> http://lists.zope.org/mailman/listinfo/zope-announce >> http://lists.zope.org/mailman/listinfo/zope ) >> > > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is there a hook for before the transaction is committed
Hi Tim, I have two suggestions, I hope one of them helps. 1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented. 2) Don't use this kind of functionality, but rather use sub-transaction commits. The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations. A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense. In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well. John Tim McLaughlin wrote: > Is there a hook for before the transaction is committed for objects which > subclass Persistent? I found __inform_commit__ for a "registered" object, > but I can't seem to get that to work as I thought it did. I also tried > subclassing TM like a DA, but to no avail. > > TIA, > Tim > > ___ > Tim McLaughlinBCSwebservices.net > Director, Technical Group 1950 Old Gallows Road > tel: (703) 790.8081 x111 Suite 201 > [EMAIL PROTECTED]Vienna, VA 22182 > www .bcswebservices. net > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ## # # Zope Public License (ZPL) Version 1.0 # - # # Copyright (c) Digital Creations. All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright #notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions, and the following disclaimer in #the documentation and/or other materials provided with the #distribution. # # 3. Digital Creations requests that attribution be given to Zope #in any manner possible. Zope includes a "Powered by Zope" #button that is installed by default. While it is not a license #violation to remove this button, it is requested that the #attribution remain. A significant investment has been put #into Zope, and this effort will continue if the Zope community #continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning #features derived from or use of this software must display #the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #In the event that the product being advertised includes an #intact Zope distribution (with copyright and license included) #then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to #endorse or promote products derived from this software without #prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain #the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #Intact (re-)distributions of any official Zope release do not #require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as #patches to official Zope releases. Distributions that do not #clearly separate the patches from the original work must be clearly #labeled as unofficial distributions. Modifications which do not #carry the name Zope may be packaged in any form, as long as they #conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPO
Re: [Zope-dev] is there a hook for before the transaction is comm itted
Hi Tim, I'm glad that worked for you. I think _vote() is the right place to do what you want. See my reply to Steve Alexander for my comments on _v_* attributes. John Tim McLaughlin wrote: > In what respect are the _v_* attribs gonna cause problems. My guestimate > was that they disappeared upon transaction commit/abort. I'm also not sure > as to why I would need subtrans since I'm only messing with properties of > the object. To my knowledge, subtrans are only necessary to conserve > resources. Anyway, what you gave me works! Thanks. It seems I need to > override the _vote method (since it is only called once and allows > exceptions). As to the other stuff, I'm sure you can enlighten me further > as to why. I appreciate the help. > > Cheers. > Tim > > -Original Message- > From: John D. Heintz [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 05, 2001 12:45 PM > To: Tim McLaughlin > Cc: '[EMAIL PROTECTED]' > Subject: Re: [Zope-dev] is there a hook for before the transaction is > committed > > > Hi Tim, > > I have two suggestions, I hope one of them helps. > > 1) Attached is a TM.py file that I wrote based on the one you mention > below. I've tried to make it more obvious and better documented. > > 2) Don't use this kind of functionality, but rather use sub-transaction > commits. > > The first suggestion has more overhead than what I assume you would > need, but the second one won't work for all situations. > > A Fishbowl proposal of mine, HashingSupport, was going to use the same > kind of hook you are asking about. In this case though, using > sub-transaction commits made a lot more sense. > > In general though, I think that _v_* attributes pose a non-trivial > problem that probably requires a hook on abort() if not commit() as well. > > John > > Tim McLaughlin wrote: > > >> Is there a hook for before the transaction is committed for objects which >> subclass Persistent? I found __inform_commit__ for a "registered" object, >> but I can't seem to get that to work as I thought it did. I also tried >> subclassing TM like a DA, but to no avail. >> >> TIA, >> Tim >> >> ___ >> Tim McLaughlin BCSwebservices.net >> Director, Technical Group1950 Old Gallows Road >> tel: (703) 790.8081 x111Suite 201 >> [EMAIL PROTECTED] Vienna, VA 22182 >> www .bcswebservices. net >> >> >> ___ >> Zope-Dev maillist - [EMAIL PROTECTED] >> http://lists.zope.org/mailman/listinfo/zope-dev >> ** No cross posts or HTML encoding! ** >> (Related lists - >> http://lists.zope.org/mailman/listinfo/zope-announce >> http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is there a hook for before the transaction is committed
Hi Steve, ZPatterns is something that is very high on my must investigate list, but I am not doing Zope development, but rather ZODB based development. I'm sure that I can still get lots of good ideas though... My comment below about _v_* attributes is primarily about not using functionality like Keeper or TM, but rather just taking advantage of _v_* attributes for caching purposes. What I would want from caching, volatile variables is to reset only when the object, or more safely the session, has conflicted and needs to be reset. I wouldn't want to take the performance hit for the cases where I have only successful commits on the same Connection cache of objects. In that case I would needlessly be reseting my volatile cache. In our code we are overriding _p_deactivate() like this: def __p_deactivate__(self): temp = _v_something Persistent.__p_deactive__(self) _v_something We are only doing this for instance vars that are not sensitive to commit/abort cycles. I think that the ideal situation would allow the volative cache to be reset only in the case of a Conflict, i.e. abort() There are two scopes that this can happen at: 1) The _v_* vars that are only local to the Persistent object that they are defined within. This would be a __p_reset__() method or something that is called by the ZODB Connection mechanism. 2) Session wide, i.e. _v_* vars that are dependent on multi-object state but happen to be stored on one of the Persistent objects. This would be handled by Keeper or TM like solutions. Anyway, this is just my current mental state dump. ;-) Thanks, John Steve Alexander wrote: > John D. Heintz wrote: > >> Hi Tim, >> >> I have two suggestions, I hope one of them helps. >> >> 1) Attached is a TM.py file that I wrote based on the one you mention >> below. I've tried to make it more obvious and better documented. >> >> 2) Don't use this kind of functionality, but rather use >> sub-transaction commits. >> >> The first suggestion has more overhead than what I assume you would >> need, but the second one won't work for all situations. >> >> A Fishbowl proposal of mine, HashingSupport, was going to use the same >> kind of hook you are asking about. In this case though, using >> sub-transaction commits made a lot more sense. >> >> In general though, I think that _v_* attributes pose a non-trivial >> problem that probably requires a hook on abort() if not commit() as well. > > > > Take a look at ZPatterns; specifically, the classes Keeper and Kept from > ZPatterns/Transactions.py > > You can see examples of how they are used in DataSkins.py and Rack.py, > although there really isn't much to it. > > I've included the docstrings below. > > class Keeper: > """Resets an object's per-transaction cache attributes at txn boundaries >Note that Keepers are created by Kept objects semi-automatically, > and there is usually no need to create one manually. A Keeper >automatically registers itself with the Zope transaction upon >creation, and instructs its Kept client to clear its per-transaction >cache at all transaction boundaries. Keeper methods are called only >by the Zope transaction, so don't mess with them.""" > > > class Kept(Base): > """Thing which has a Keeper to clear its per-transaction cache. > > Objects derived from Kept should reference the 'self._v_Keeper' > attribute whenever they need to flag that they have made changes to > their cache that would require it to be cleared. (Note that > '_v_Keeper' is an *attribute*, not a method, and so should not be > called, just referenced.) > > Once this has been done, the next transaction state transition > that occurs (sub/main transaction commit or abort) will cause > the object's Keeper to call for a cache reset. > > Subclasses of Kept should define a '__per_transaction_cache_attrs__' > attribute as a sequence of attributes which they would like to have > deleted from their '__dict__' at reset time. > """ -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
at we want to be able to work with > representations of objects using tools like emacs and dreamweaver. In > fact, we'd like to use emacs as our front end to CVS. The ideal > situation would be to edit Zope objects in emacs, publish them to a Zope > object database, test them (perhaps using a separate web browser like > Netscape or Internet Explorer), and then once everything is working, > commit the objects to a CVS repository (using emacs or from the command > line). > > >> If you want a lossless "morally binary" representation, it's >> probably best to use XML export, which is great for your >> purposes, because it already exists! ;-) > > > I've heard it said that all progress is due to the unreasonable man. So > to do my part for progress, what I want is a lossless "morally plain > text" representation. ;-) > > If the existing XML export really was great for our purposes, I'd be > done! The problem is that everything comes out in one big monolithic > file. That's not good for project management using CVS. (At least, as > far as I can tell.) > > I think there is the potential for a really good solution that solves > our need to manage our project via CVS, and to solve the greater need to > enhance the Zope management interface to support tools that work with > filesystem objects. > > I am about to jump into this project next week. I do want to stay in > touch with anyone who is working on similar projects, so please keep in > touch! I will post reports as I make progress in case anyone is > interested. > > Thanks, > Fred -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
ialized as binary for lots of good reasons. Just listing that my example serialized file is used by some other objects doesn't help because ZCatalog may not refer directly to the object anyway. The editing and import process must work together to track changed files, moved files, and deleted files at a minimum. This may not be good enough, because the code written into a Zope Product may say that when property "x" is changed on these objects to reindex the "foo" ZCatalog for that object. When I import the object from the serialized format all I can know is that something changed, but without expensive processing (XML diffing is hard in the general case, we might be able to limit the structures to managable scope though) we can't know that the "foo" ZCatalog should be updated instead of the "bar" ZCatalog. > > >> a) XML is structured enough that it can reliably hold the >> data from the >> ZODB. The current XML dump is not useful for this - it >> would need to >> create individual files and folders to represent >> containment. > > > This is pretty easy right now. Ten lines of recursive code > can walk the whole tree if necessary and export only leaf > objects. > > >> b) A hybrid XML and custom dump solution. An Image for >> example could >> dump out as a binary image file with meta-data in a >> similiarly name XML >> file. > > > Yes, each object should make its own policy regarding its > body. Its metadata format should be standardized, however. > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
ctured enough that it can reliably hold the >>>> data from the >>>> ZODB. The current XML dump is not useful for this - it >>>> would need to >>>> create individual files and folders to represent >>>> containment. >>> >>> >>> This is pretty easy right now. Ten lines of recursive code >>> can walk the whole tree if necessary and export only leaf >>> objects. >> > > Great. Maybe I am closer than I realize to the CVS management > solution. I need to look more closely at ZCVSmixin to see what it > does. But for our immediate need (which is to allow a distributed team > of developers to share code and track changes via a central CVS > repository), maybe it makes the most sense just to segment the existing > XML export into directories and files and enhance the existing import to > allow overwriting objects. > > >>>> b) A hybrid XML and custom dump solution. An Image for >>>> example could dump out as a binary image file with meta-data in a >>>> similiarly name XML file. >>> >>> Yes, each object should make its own policy regarding its >>> body. Its metadata format should be standardized, however. >> > > I like this idea. > > After I have the XML export/import working in a way that fits better > with CVS (even if the sreialized representation is essentially a black > box), then I can tackle how each object represents its body in a > "morally plain text" serialized format. I want to add here that it may be very useful to not specify that any object have only one serial format separate from the XML default. Specifically it might make it an easier problem if the author of the export code for a type of object can dump property "x" as -x. and property "y" as -y. For example instead of just: | -- foo_page.xml -- foo_page.dtml it might be useful to have arbitrary other files created when foo_page is dumped: | -- foo_page.xml -- foo_page.dtml -- foo_page-description.txt This would imply that the description property is not captured in the foo_page.xml,but instead the easier to use text file. I'm worried about the parsing complexity when trying to build a single "morally plain text" serialized format, and I think that "morally plain" can be applied at a sub-object level to make it easier to work with. The example that comes to mind it Image: | -- icon.xml -- icon.png -- icon-description.txt The "morally plain" output here would be binary, not text. A single output file would be hard pressed to allow binary and text editing in the same file. John -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Chris McDonough wrote: >> I think there is really only one issue nobody has been able to sort out: >> do we want the objects to be actually stored on the filesystem or do we >> want to be able to mirror a ZODB? Or do we want both? > > > My conception of it is that objects won't be served from the filesystem, but > just put in a editable serialized format for version control and tool > purposes. How useful/difficult would it be to put the SMB protocol on top of a ZEO server? As serialized formats are build, would this be useful to anyone? Another use for this that I think would be great for is schema migration. Right now with ZODB we can have custom __setstate__() methods that do schema migration, but being able to perform text processing changes with common tools would be great. Just thinking out loud... > > >>> Nobody wants to edit XML, AFAICT. >> >> Careful, that's a religious issue in some circles. :-) I know of many >> people who prefer that data be stored in XML just because humans can >> read and change it if the need arises. (This from a guy who has >> actually edited ZODB XML export files. :-) > > > Eek. ;-) > > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] External transaction integration bug?
I can't directly address the concerns you've raised, but for my project I have rewritten TM.py to work better within the begin/vote/finish/abort protocol framework. I've also added more documentation. John Randall F. Kern wrote: > I may just be missing something obvious here, but it seems like there is > a hole in ZODB.Transaction.Transaction.commit and Shared.DC.ZRDB.TM.TM, > that can cause external transactions (those that use the TM mixin class, > like psycopg) to be abandoned (never get committed or rolled back). > > Let's say somewhere around line 300 in Transaction.py (the call to > j.commit(o, self)) we get an exception. Furthermore, let's say the TM > derived database object has already been committed (the only effect of > which is to move the DB into the jars mapping, since TM.tpc_begin() and > TM.commit() both do nothing). > > The exception dumps us down to about line 353, where we call > _p_jar.abort() on all the uncommitted objects (note: it's important that > the database connection isn't in this list, because TM.abort() will > rollback the transaction. the way we keep the db out of this list is by > having it appear in objects _before_ the object that failed the commit). > > Next we reach line ~366, where we should "unwind TPC for the jars that > began it". What this means is calling tpc_abort() on each jar from the > objects that were already committed (which includes the database). > However, TM.tpc_abort() does nothing, leaving the external database > transaction open. > > Does this make sense? > > If this makes sense (i.e. seems bad :), does catching tpc_abort() in TM > and calling TM.abort() seem like a valid fix? > > Thanks, > -Randy > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > > > ## # # Zope Public License (ZPL) Version 1.0 # - # # Copyright (c) Digital Creations. All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright #notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions, and the following disclaimer in #the documentation and/or other materials provided with the #distribution. # # 3. Digital Creations requests that attribution be given to Zope #in any manner possible. Zope includes a "Powered by Zope" #button that is installed by default. While it is not a license #violation to remove this button, it is requested that the #attribution remain. A significant investment has been put #into Zope, and this effort will continue if the Zope community #continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning #features derived from or use of this software must display #the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #In the event that the product being advertised includes an #intact Zope distribution (with copyright and license included) #then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to #endorse or promote products derived from this software without #prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain #the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #Intact (re-)distributions of any official Zope release do not #require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as #patches to official Zope releases. Distributions that do not #clearly separate the patches from the original work must be clearly #labeled as unofficial distributions. Modifications which do not #carry the name Zope may be packaged in any form, as long as they #conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN
Re: [Zope-dev] Experiments with ORMapping
I think this is a great idea! I would definetely like to use and contribute to this effort. Having this kind of flexibily would be fantastic. After demonstratable Python code is working I would request that usability issues (UI Schema mapper, data migration/schema evolution tools, ZEO integration, multi-Storage uses) be addressed sooner than later. John On Monday 14 May 2001 10:47, Shane Hathaway wrote: > Chris Withers wrote: > > Shane Hathaway wrote: > > > I'm telling you there's a lot more you can do with the code that makes > > > > > > > > > The next thing to do is to write a fishbowl proposal. > > > > This sounds cool but made my head hurt :-S > > > > Can you try and bring this back down to the level of us mere mortals by > > explaining how your OR stuff would let me take a table of data in an > > RDBMS table and have it appear as objects in the Management Inteferace? > > Sorry, this is at a pretty low level and I do need to explain it better. > > One would define an "ObjectMappingSchema" whose job it is to store and > retrieve objects of a specific type and in a specific location. It > would usually grab a database connection object to do its work. When > loading, it would perform a query then manually put attributes into a > persistent object. When storing, it would grab specific attributes from > the persistent object and execute a statement to store those attributes. > > So let's say you want a ZODB to store and retrieve users in a specific > table while putting everything else in pickles. You would create an > instance of PickleSchema, which implements the ObjectMappingSchema > interface, and tell it to manage everything *except* the users mapping > in BasicUserFolder objects. You would tell it to store and retrieve > this object using your UserFolderSchema instead. Your UserFolderSchema > would store and retrieve the users from the USERS and USER_PREFS > tables. The user table wouldn't require the use of OIDs but would > require unique user IDs. > > So in the management interface nothing would change. Nor would the > application-level Python code. You would only define a layer that maps > objects to a relational database. You would still see the user folder > as you do now. > > Now, it may be useful to provide a management interface for defining the > schema mapping. I haven't approached that yet; AFAICT this is where the > work done on SmartObjects and DBObjects would be very useful. Initially > I was planning for people to code the mapping purely in Python so we > could gain experience and find common patterns before inventing a UI. > > Shane > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Experiments with ORMapping
A way to approach how this would be useful would be to contrast different use environments for ZODB code. The same code could be used for: - Unit testing, prototyping, and general exploration could use ZODB with DemoStorage and the default Connection objects. - Production use could make use of ZODB and custom Connection objects that map to/from relational tables. John On Monday 14 May 2001 09:51, Chris Withers wrote: > Shane Hathaway wrote: > > I'm telling you there's a lot more you can do with the code that makes > > > > > The next thing to do is to write a fishbowl proposal. > > This sounds cool but made my head hurt :-S > > Can you try and bring this back down to the level of us mere mortals by > explaining how your OR stuff would let me take a table of data in an RDBMS > table and have it appear as objects in the Management Inteferace? > > I know that's horribly oversimplified, but some of us only have small > brains ;-) > > cheers, > > Chris > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] another Zope hanging..
I've added a patch to Python 2.1 on sourceforge that helped me considerably when diagnosing multi-threaded Python lock ups. See http://sourceforge.net/tracker/index.php?func=detail&aid=421709&group_id=5470&atid=305470 for the submitted patch. I created this to give me at least as much functionality as Java has to dump the stack trace of all Java threads and Java monitors. For an example of how I used it see http://lists.zope.org/pipermail/zodb-dev/2001-May/000703.html in the ZODB dev list. Hope this helps, John On Friday 18 May 2001 09:13, Christian Scholz wrote: > Hi! > > Just FYI: The server still hangs once a day and another one is doing > the same.. > It even does this when simply accessing one page or image over and over > again. > More precisely I've started the server and did > > ab -n 10 -c 10 http://foo.bar/we/pics/someimg.gif > > (ab being the apache benchmarking utility) > > and after a while I get the broken pipe error. > > I've also changed my python version to 2.0 and tested it with this > but still the same effect. Also changing the server (and thus > hardware and system) did not help it. > I've also removed the mysqlda from the zope installation but also this > did not help.. > I will try now to create the smallest version of the site that still > hangs.. > > Dunno if anybody has some idea, I actually have none.. > > I'll keep you informed.. > > -- christian > > PS: strangely it works on the development server but also here I am doing > some tests with ab right now.. and this one is still 1.5.2 > > On Thu, May 03, 2001 at 02:16:30PM -0400, Chris McDonough wrote: > > > Well, my problem might be that in my case most sql statement are done > > > > inside > > > > > some attribute provider of ZPatterns.. This is using ZSQL methods > > > > internally > > > > > but actually those then won't show up I guess.. > > > > Even if you weren't using ZPatterns, the error probably wouldn't jump out > > and say "here I am!" So I don't think there's much difference between > > using ZPatterns and not using ZPatterns. The process of detecting when > > something hangs is just like any other troubleshooting process, it's a > > matter of exclusion. If you notice that the request named > > "foobargorf/fleafang" *always* hangs, you investigate what it does, and > > try to reproduce it. If it's incidental, so be it, and move on to the > > next theory. > > > > > I've also seen that some more recent version of the mysql stuff is > > > around and I am using this now.. > > > > > > The problem's also that I just have a few methods to invoke from the > > > > outside > > > > > which do lots of things by calling other object. Thus I might not > > > really > > > > see > > > > > what's really causing the problem.. I hope though that my upgrade will > > > > show some > > > > > benefit.. > > > > The -M log perhaps won't show you the actual operation that's causing the > > hang, but it will show you the entry point into a routine which causes > > the hang. It's your job from there to track down the cause. This is > > just like debugging a program. You get an error somewhere, and you need > > to track it back to its root, which may be six levels up the call stack > > buried in some godforsaken regex. ;-) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bulletproof ZCatalog proposal
Me too! Me too! John On Thursday 07 June 2001 08:49, Chris Withers wrote: > Shane Hathaway wrote: > > But I think I have a solution for all of the issues in conflict > > resolution. If you, or anyone else, is also interested in this, please > > show support (if only by saying "please do this"!) :-) I can't work on > > it unless I have a reason to. > > Please do this! :-) > > I'm particularly interested in ZCatalog becoming a standard ZODB feature, > and I know there are otehrs on ZODB-dev who are dying for this right now... > > cheers, > > Chris > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bulletproof ZCatalog proposal
Please remove the del statement in the ZODB __init__.py file to make this possible. I am simply trying to create my own Transaction objects and can't without patching the StandaloneZODB release to do this. Thanks, John On Friday 08 June 2001 16:21, Phillip J. Eby wrote: > At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote: > >On Thursday 07 June 2001 21:28, Phillip J. Eby wrote: > > > Upon being told to perform a transaction or subtransaction commit, > > > the transaction would notify all the ruleAgents, and then all the > > > indexingAgents. Objects could still subscribe to either queue while > > > this notifying is taking place. (So that triggered actions could > > > cause indexish objects to register as indexingAgents, not to mention > > > causing updated objects to fire additional triggers.) > > > > > > Once all agents in a queue are notified, that queue should be cleared > > > so that notifications are on a per-subtransaction basis. Once both > > > queues are cleared, normal transaction behavior goes forward. > > > >Would you say this would occur before tpc_begin() messages or just > >after? > > Before. I'm saying this would take place immediately at the start of the > existing Transaction.commit() method. > > > > Hm. That's simpler than I thought it was going to be. Shoot, I can > > > even see how to implement it as a runtime patch, that would've been > > > simpler than all the shenanigans ZPatterns goes through to fake out > > > the transaction machinery... and it's a better > > > implementation. Ah well. At the time I wanted to avoid trying to > > > convince Jim to add machinery to transactions "just" for ZPatterns, > > > given that ZPatterns wasn't a particularly established product at the > > > time. > > > > > > Let me know if you guys put something like this in, though, and I'll > > > definitely look at reworking ZPatterns to use the mechanism. It > > > could potentially cut a lot of code out and improve the robustness at > > > the same time. > > > >I don't foresee us adding this capability right away since we need to > >understand it better and it only applies to one working product and a > >hypothetical product. I'd suggest you go ahead with the runtime patch. > > I think I'll wait until ZPatterns works with Zope 2.4, unless it becomes > necessary otherwise. Replacing what I've got now is a pretty significant > undertaking, and risk-prone to boot, so I don't want to delay the finishing > of ZPatterns' support for Zope 2.3.x. > > Basically, the runtime patch would be to replace > ZODB.Transaction.Transaction with a subclass that implemented the > notification queues in the commit() method. There'd be a few other little > extensions needed, like clearing the queues on any abort operation, and > adding registerIndex() and registerRule() or some such methods. > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
OracleStorage? Re: [Zope-dev] DCOracle2 Beta 3
Are there any plans to port OracleStorage over to use DCOracle2? John On Tuesday 12 June 2001 10:46, Matthew T. Kromer wrote: > For all of you (or at least, BOTH of you) Oracle users out there, > I packed up DCOracle2 Beta 3 this morning, including Z Oracle Stored > Procedures as part of ZOracleDA. > > It can be found in the usual place, > > http://www.zope.org/Members/matt/dco2 > > This isn't much different from Beta 2 except for some SP tweaks and the > Z Oracle Stored Procedures, except that the NT builds are release > versions with Oracle 8i (e.g. SP discovery code) features enabled -- > when I built Beta 2 I goofed the build and packaged a debug release > without the 8i specific features on. > > I'll confess that I'm not a heavy user of Stored Procedures, so your > mileage may vary; particulary when using IN/OUT binds where type > conversions need to take place from unweildy Oracle native types (like > SQLT_NUM.) > > If you play with the stored procedure objects in Zope, it's probably > worth pointing out that the default permissions won't include execute > permission -- you have to specifically enable that for non-manager roles. > > On the far-out front, a few people have asked how you might do > user-specific connections to the database (ie instead of pooling by a > common connection, you individually authenticate to Oracle with your own > password). Clearly, cloning the base Connection object would be fairly > straighforward, but authenticating it to Oracle would not be, as the > user password wouldn't be available. If anyone feels strongly about > that (ie you have a notion on how you would make it work and/or you need > it), feel free to write me. From a performance standpoint it would be > terrible, but security auditors would love it. > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
