Re: [Zope-dev] Product Data Storage
You should look into using ZCatalog for this purpose. -josh zeidner
I have an interesting issue which I don't think has been raised. But instead of solving the issue myself I thought I would share it with you guys/gals and see what you think.
I am currently working on a Zope MailIn product, which allows you to send emails directly in to Zope. Version 0.1 can be found at: http://www.zope.org/Members/NIP/ZMailIn
In version 0.2 I plan to have a ZMailIn python product which will handle the Zope side of things and behave a bit like a client. For example you could add a ZMailIn product instance in to Zope and configure it to receive all emails for bob@bobscompany.com and provide a method to execute upon mail arrival.
This is great and you could have n ZMailIn product instances throughout your Zope site and in any position.
When email arrives I need to find all the ZMailIn instances within the ZODB and hand the email to the correct one.
I have decided AGAINST searching the ZODB for instances of ZMailIn because that is just too scary, hideously inefficient and I don't want to go there. Instead I thought of keeping an up-to-date list of where all the current instances where held. My original idea was to get the ZMailIn product to write a file in to the /lib/python/Products/ZMailIn directory, which shouldn't cause any problems that I can see.
However, It had occurred to me that with the current growth of Zope it was going to become more popular that separate Zope instances of the same product may need to share some data.
So my question is this: What are peoples opinions on storing shared product data? Where should it be placed? Should this ability be added to Zope as a standard?
Thanks in advance. -Andy Dawkins (New Information Paradigms Ltd)
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
You should look into using ZCatalog for this purpose.
OK - that is a solution that could solve my particular issue, but where would you put it? Would you put it in the Product folder, or in some common place in the ZODB. How would you create it originally? In the products __init__.py or by some kind of DTML method. Also would the ZCatalog be appropriate for storing general information to be shared between instances, Maybe some global configuration options. I am looking for a generalised method of storing Class Level Variables. Maybe properties within the Product folder. But above all I am looking for a method of doing this that the Zope community agrees as being efficient and recognises as being _the_ solution to the problem. I want to avoid a 'hack' solution if possible. -Andy Dawkins (New Information Paradigms Ltd)
This issue sounds similar to ZScheduler's Schedule catalog. In that case we decided to put the Schedule in the root folder. There is no more global data than the catalog itself, but if there were it could be stored in the catalog folder, since catalogs are folderish. There used to be some code in ZScheduler to make the Schedule undeletable, but I took it out during development because I got locked out too often. I may put it back in later. I can make it public if you'd like. ZScheduler's __init__.py method creates this global data structure if and only if it doesn't already exist. Because ZScheduler creates it, it can assign the appropriate permissions and methods to manage the global structure any way it wants. -- Loren
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Andy Dawkins Sent: Friday, June 30, 2000 07:02 To: Josh Zeidner; zope-dev@zope.org Subject: RE: [Zope-dev] Product Data Storage
You should look into using ZCatalog for this purpose.
OK - that is a solution that could solve my particular issue, but where would you put it? Would you put it in the Product folder, or in some common place in the ZODB. How would you create it originally? In the products __init__.py or by some kind of DTML method.
Also would the ZCatalog be appropriate for storing general information to be shared between instances, Maybe some global configuration options.
I am looking for a generalised method of storing Class Level Variables. Maybe properties within the Product folder.
But above all I am looking for a method of doing this that the Zope community agrees as being efficient and recognises as being _the_ solution to the problem. I want to avoid a 'hack' solution if possible.
-Andy Dawkins (New Information Paradigms Ltd)
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Loren Stafford wrote:
In that case we decided to put the Schedule in the root folder. There is no more global data than the catalog itself, but if there were it could be stored in the catalog folder, since catalogs are folderish.
Hmm, this is messy. Could the Catalog not be stored in your case in: /Control Panel/Products/ZScheduler and in Andy's case in: /Control Panel/Products/ZMailIn ? I like your point about ZCatalog's being folderish though ;-)
ZScheduler's __init__.py method creates this global data structure if and only if it doesn't already exist. Because ZScheduler creates it, it can assign the appropriate permissions and methods to manage the global structure any way it wants.
This sounds like what you want to do, Andy... cheers, Chris
I haven't thought much about this; I just followed mj's original design. Maybe there was some reason for this decision. Any comment Martijn? -- Loren
Loren Stafford wrote:
In that case we decided to put the Schedule in the root folder. There is no more global data than the catalog itself, but if there were it could be stored in the catalog folder, since catalogs are folderish.
Hmm, this is messy. Could the Catalog not be stored in your case in: /Control Panel/Products/ZScheduler and in Andy's case in: /Control Panel/Products/ZMailIn ?
On Fri, Jun 30, 2000 at 12:48:54PM -0700, Loren Stafford wrote:
I haven't thought much about this; I just followed mj's original design. Maybe there was some reason for this decision. Any comment Martijn?
Loren Stafford wrote:
In that case we decided to put the Schedule in the root folder. There is no more global data than the catalog itself, but if there were it could be stored in the catalog folder, since catalogs are folderish.
Hmm, this is messy. Could the Catalog not be stored in your case in: /Control Panel/Products/ZScheduler and in Andy's case in: /Control Panel/Products/ZMailIn ?
I put the ZScheduler object in the root folder for acquisition reasons, so that it could be found by all event objects. Technically, there is no reason to move this to a different, known path of course. But I do think that placing this information in /Control_Panel/Products/* is a bad idea, for the same reason that placing software data in /usr/bin is bad. You want to keep source/binaries and data separated. Maybe you can add a subobject to Control_Panel itself: /Control_Panel/ZScheduler. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio -----------------------------------------------------
participants (5)
-
Andy Dawkins -
Chris Withers -
Josh Zeidner -
Loren Stafford -
Martijn Pieters