May 2000 - Zope-Dev - Zope lists

Re: [Zope-dev] Alternative Storages: (was RelationalStorage (was LocalFS))
by Jimmie Houchin 04 May '00

04 May '00

When I wrote my notes I didn't know of RIPP. When I wrote the message my thoughts/thinking had not been revised to include RIPP. However now that you mention it. :) I have read your PP version. I like what I read. At my earliest opportunity I plan on looking a ZPatterns and working on wrapping my mind around the RIPP. I reasonably well understood what I read, but it still requires a pardigm shift to change the way you think or address the problem. I think the Rack system can, from my understanding, handle the requirements I listed in my post. Basically, the ability to place certain objects with their own distinct storage characteristics in an appropriate storage. What would complement Rack storage well and is basically the topic is multifile ZODB. If the ZODB had multifile capability and each Rack could name it's file and path that the ZODB uses. Then we would have an excellent balance between transparency of storage and capabilities. Thanks for the input. Jimmie Houchin At 7:01 PM -0500 5/3/00, Phillip J. Eby wrote: >At 05:27 PM 5/3/00 -0500, Jimmie Houchin wrote: >> >>As far as usage is concerned I generally like the ZODB best because it >>is reasonably transparent to the building of a web app with Zope. >>However there are areas in which it does not currently excel that which >>if your site requires these skills then alternatives must be used. A >>couple of areas are data size and heavy writes. > >Agreed. > > >>Some people use an RDBMS to solve these issues. While this will work it >>does expect more from the developer. Some do not have the skills or the >>tools. Even if one does it still requires leaving the transparency of >>developing with the ZODB. > >Ty and I are working on fixing that. As of today, the Specialist+Rack >subsystems of the ZPatterns library are now capable of managing objects >with mixed-source attributes and property sheets. That is, objects stored >in a Rack can have attributes and property sheets whose data comes from >non-ZODB sources. Currently, no non-ZODB sources are implemented, alas, >and the mechanism is only applicable to rack-mounted objects. In future >releases, we'll be adding SQL and LDAP data sources, and the ability for >any Zope object to take advantage of these abilities (as long as it >subclasses RackMountable, and knows how to find the "designated Rack" which >will provide support for the desired features). > > >>Class/Object based db files. >> >>Each class gets it's own db file. This could be similar to the current >>ZODB file except specific to a class. As objects are created they are >>appended to the db file for their class. This could be somewhat > >>analogous to tables in an RDBMS. >> >>Advantages would be spreading out the data space over multiple files >>which would help with some oses. Also I think that each class has >>different characteristics which would be able to be managed better if >>separate. >> > >Basically, what you've described could be considered an instance of the >Specialist and Rack patterns of the RIPP model, but with a less flexible >implementation. That is, you can do what you just described using the >Specialist/Rack patterns, but what you described won't do everything >Specialist/Rack can (such as mixed-source data for the same object or a >sensible place to put class extent methods (e.g. find, listAll, that sort >of thing)). > >The only thing missing from Rack today that would be needed to implement a >"ZODB per class" approach, is the ability to use an alternative >"persistence provider" for storage. I'd like to see some discussion on a >mechanism for providing such things. My thought is that they would sort of >look like SQL Connection objects: something you can add, that can be >acquired, and which Racks can select from a dropdown. (The dropdown even >already exists in the about-to-be-released ZPatterns 0.3.0, it just is >empty except for an option to use the primary ZODB.) > >The thing about these "persistence providers", though, is that they need to >provide some kind of root for each thing that wants to use them. I'm >assuming each provider may be shared by more than one Rack or rack-like >object, that security constraints need to exist on who can create root >branches in these DB's, and that the branches need to be able to be removed >when their owners go away. If there were a design (or implementation, >better yet) for gizmos like these, hooking up Racks to use them would be a >snap, since all Racks need to do is store a single BTree. > >(By the way, Racks can be written to store the "base" object data in an >RDBMS, db file, LDAP, or anything else that you can implment createItem(), >retrieveItem(), and deleteItem() methods for.)

3 2

Re: Alternative Storages: (was RelationalStorage (was LocalFS))
by Jerry 04 May '00

04 May '00

Just one point. The concept of abstraction to enable any SQL compatible RDBMS makes perfect sense, to a rigorously OO way of thinking. Ironically, strict adherance can sometimes lead down a path where a truly marvelous option is dismissed, simply because it is unique. The objects to be stored are, after all, objects, not data fields. The shortcomings of FileStorage are limitations related to heavy writes, and non-atomic undo. Other aspects have proven very appropriate for the task of enabling persistence in objects. The inherent features of PostgreSQL to allow user defined, inheritable datatypes, suggests remarkable synergies with the intention of the proposed DB Storage, if not with every stated goal. It seems a shame to ignore this possibility just because Oracle / MySQL have so much mindshare. When such a tool exists that excels at storing objects, in a tabular sort of way, should it's special talents be disregarded just to avoid overdependence on an incomparably suitable solution? In the worst case, perhaps a PostgreSQL implementation of a Rack could be expected to directly handle aspects of Object Persistence that must be supplemented with Property Sheets, etc. in alternate implementations. Just in case a Zope newbie is reading this, and hasn't heard of PostgreSQL before, it is also Open Source. http://www.postgresql.org Later, Jerry S.

3 2

Re: [Zope-dev] Alternative Storages: (was RelationalStorage (was LocalFS))
by Jason Spisak 04 May '00

04 May '00

Phillip J. Eby: > > Basically, what you've described could be considered an instance of the > Specialist and Rack patterns of the RIPP model, but with a less flexible > implementation. That is, you can do what you just described using the > Specialist/Rack patterns, but what you described won't do everything > Specialist/Rack can (such as mixed-source data for the same object or a > sensible place to put class extent methods (e.g. find, listAll, that sort > of thing)). > What about storing the class data itself in a Rack? Is there any limitation to what you can put into a Rack. I am only asking this to clarify what we are heading towards. Somewhere to put just the instance data. > The only thing missing from Rack today that would be needed to implement a > "ZODB per class" approach, is the ability to use an alternative > "persistence provider" for storage. I'd like to see some discussion on a > mechanism for providing such things. My thought is that they would sort > look like SQL Connection objects: something you can add, that can be > acquired, and which Racks can select from a dropdown. (The dropdown even > already exists in the about-to-be-released ZPatterns 0.3.0, it just is > empty except for an option to use the primary ZODB.) So a "standard" ZODB connection from which a class can get it's data which can be fulfilled by anything inherited from BaseStorage? > > The thing about these "persistence providers", though, is that they need to > provide some kind of root for each thing that wants to use them. Is that for acquisition sake or class container sake or what exactly? >I'm > assuming each provider may be shared by more than one Rack or rack-like > object, I agree. > that security constraints need to exist on who can create root > branches in these DB's, and that the branches need to be able to be removed > when their owners go away. If there were a design (or implementation, > better yet) for gizmos like these, hooking up Racks to use them would be a > snap, since all Racks need to do is store a single BTree. > > (By the way, Racks can be written to store the "base" object data in an > RDBMS, db file, LDAP, or anything else that you can implment createItem(), > retrieveItem(), and deleteItem() methods for.) > I've gone over you ppt presentation 3 times to try to soak it up, so forgive me if I am missing a few things. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 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.

2 1

__init__.py
by Chris Withers 04 May '00

04 May '00

Hi, In the process of re-engineering Squishdot to use Catalogs I bumped into __init__.py and wondered if this was out of date as well. I can't tell though 'cos I can't find any documentation on __init__.py, old or new, to work from. Is there any? Also, is there something like a How-To for creating python products (in particular; what should go into __init__.py and what should go into ProductName.py?) using the latest, future proofed, methods? cheers for any help, Chris

4 5

Download the active dtml-document.
by Juan Javier Carrera Obrero 04 May '00

04 May '00

Hello, Anybody knows to how to download the active dtml-document ? I can not use WinZip because the dtml-document is generated of dinamic way. I am trying that the dtml-document (.html) was opened with Microsoft Word but that it can be modified. Thanks. JUAN JAVIER CARRERA OBRERO e-mail: jcarrera(a)uco.es

1 0

Re: [Zope-dev] absolute_url() and DTML Methods
by Tres Seaver 04 May '00

04 May '00

Chimezie Thomas-Ogbuji <cogbuji(a)fourthought.com> wrote: > > you should be able to append <dtml-var id> to the absolute_url() method > call. Althought I'm not sure if it that will append the id of the > containing object or the id of the DTMLmethod itself (if it's the latter > then that should work for you). So this is what you want: > > absolute_url() + "/" + <dtml-var id> Actually, DTML methods don't expose their own 'id' (under that name), but that of their acquisition context. You need to use 'document_id' for what you want:: absolute_url() + "/" + <dtml-var document_id> > > Chimezie > > Christian Scholz wrote: > > > > Hi! > > > > On Mon, May 01, 2000 at 10:27:56AM -0700, David Brown wrote: > > > Why is it that when I call absolute_url() on a DTML Method, I get the > > > URL of the enclosing container, not the DTML Method within that > > > container? > > > > I think (but I am a newbie) that's the difference between dtml methods > > and documents. Methods simply act as methods to the containing folder and > > document are "real" objects. Thus moving from a method to a document > > should change this behaviour. > > > > > Is there an equivalent method that will give me the real location of the > > > DTML Method? > > > > Well, this I actually don't know.. Tres. -- ========================================================= Tres Seaver tseaver(a)digicool.com tseaver(a)palladion.com

4 3

IMAP server
by Michel Pelletier 04 May '00

04 May '00

Ok, some people asked me to post the IMAP server code, it is at: http://www.zope.org/Members/michel/MyWiki/IMAPServer I have not worked on this in a while but I did put a lot of notes in the Wiki. This is not IMAP in Zope, this is not even IMAP, yet. -Michel

1 0

losing security tab
by Josh Zeidner 03 May '00

03 May '00

hello, I am experiencing a weird problem with Zope and IE. When I authenticate as the administrator, everthing is ok. But when I authenticate as someone else, I lose the security tabs- but when I reauthenticate as admin, I dont get the security tabs back. Maybe this is a problem with the way I am authenticating, maybe it is a problem with Zope. CAn anyone help? -Josh Zeidner ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

ZCatalog's QueryObject
by Chris Withers 03 May '00

03 May '00

"Querying the Catalog in powerful ways involves knowing how to build this QueryObject." ...from the Interfaces Wiki. Sadly, the QueryObject page is blank. Any ideas where I can find documentation of building complex query objects from python and maybe DTML?(which might be stupid, if so, tell me ;-) Also, am I correct in guessing that Catalog/ZCatalog stores references to objects by their path? Evan Simpson made some references to this with regards to SiteAccess and with the SiteAccess functionality being (eventually) rolled into Zope, I was wondering whether (and if it'd be possible) to store the references in some way that things don't break if you catalog them through one domain and get them back as search results from another domain? cheers, Chris

1 0

Rolling back an external action when a transaction is aborted
by Itamar Shtull-Trauring 03 May '00

03 May '00

I'm communicating with an external entity (asking for payment from CyberCash), so if the current transaction fails I'd like to cancel the payment. The correct way to this is to subclass Shared.DC.TM.TM and then override the _abort() method, right? -- Itamar S.T. itamars(a)ibm.net

1 0