Mozy Online Backup: 2GB Free. Automatic. Secure.

Subject: Re: transacting multiple databases - msg#00185

List: web.zope.zodb

Date: Prev Next Index Thread: Prev Next Index

hazmat wrote:
ok, but as long as zodb works with python2.1 it will ship with extension class, so out of the box standalone zodb can use this for mounting zodb with python 2.1, and assuming mounted zodb becomes a feature with zope3, it would be reasonable to expect a similiar facility for zodb3.5/4, such that mounting can be considered a useful feature of zodb without zope?

Hmm, you reminded me of something. The current mounting code depends entirely on __of__(), but Zope 3 will not use ExtensionClass, and there is no equivalent to __of__() in Python itself, even with new-style classes. So the current strategy will not work in Zope 3. But that's not a problem because...

having cross db references would rock as well, but mounting is pretty useful as is, imo.

... for Zope 3 we should plan to do all "mounting" using cross-database references. It will be faster and more seamless. There won't be a "mount point" object that conceals itself; instead, ZODB will just know to load the mounted object from a different database. The application will have to work hard to know that any mounting is going on, whereas today the application has to do all the work.

OTOH AdaptableStorage provides a very different way to mount data from multiple sources, and it already works with the current ZODB code. I'll explain how this works soon. (I think I'm starting to get a feel for how it is that Alan Cox can work on three branches of the Linux kernel at the same time. ;-) )

It will be easy to get everything working together with mounting,
though. In addition to the setLocalTransaction() method, we might have
a setTransaction() method which lets the mounting machinery put both
connections in the same transaction. Or perhaps we could make
connections aware of when they are mounted and pull the transaction from
their parent automatically. Hmm, for better encapsulation, the second
option seems best, since right now we're stuffing an extra attribute in
the mounted connection anyway.

perfect, thats so much easier than what i was prototyping, a corollary to the aftermidnight programming rule should include no jetlagged programming :-),

True, but programming *on the plane* can be a good thing. :-)

I think the next step is to decide whether the setLocalTransaction()
code ought to be merged into mainline ZODB. I'd be happy to do it with
Jeremy's approval. (Jeremy, are you reading?)

+1, its useful and often requested here.
Christian described the justification very well, BTW.

Shane

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list - ZODB-Dev@xxxxxxxx
http://lists.zope.org/mailman/listinfo/zodb-dev

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: transacting multiple databases

On Tuesday 10 December 2002 06:51 am, Shane Hathaway wrote: > hazmat wrote: > > i thought mounted storage were a zodb feature not a zope one? (at least > > infrastructure code for them is in the ZODB package). a thought related > > to allowing mounted storages to participate in local txn. when the > > mounted storage is opened/traversed (in a getattr sense) it can register > > a MountedLogicalTxn with the parent connection transaction. the mounted > > txn can act in effect as a local transaction to the mounted storage. it > > will proxy txn messages from the parent txn to its registrants. > > It's not really a ZODB feature, since it relies on a feature of > ExtensionClass that ZODB does not use: __of__(). I put Mount.py in the > ZODB package because I also thought at first that it was a ZODB feature. > :-) ok, but as long as zodb works with python2.1 it will ship with extension class, so out of the box standalone zodb can use this for mounting zodb with python 2.1, and assuming mounted zodb becomes a feature with zope3, it would be reasonable to expect a similiar facility for zodb3.5/4, such that mounting can be considered a useful feature of zodb without zope? # gratitous code ;-) from ZODB.Mount import MountPoint from ZODB import DB, FileStorage class FSMount(MountPoint): def _createDB(self): return DB(FileStorage.FileStorage(self._path)) db = DB(FileStorage('test')) conn = db.open() conn.root()['mount1'] = FSMount('test2') having cross db references would rock as well, but mounting is pretty useful as is, imo. > It will be easy to get everything working together with mounting, > though. In addition to the setLocalTransaction() method, we might have > a setTransaction() method which lets the mounting machinery put both > connections in the same transaction. Or perhaps we could make > connections aware of when they are mounted and pull the transaction from > their parent automatically. Hmm, for better encapsulation, the second > option seems best, since right now we're stuffing an extra attribute in > the mounted connection anyway. perfect, thats so much easier than what i was prototyping, a corollary to the aftermidnight programming rule should include no jetlagged programming :-), > > I think the next step is to decide whether the setLocalTransaction() > code ought to be merged into mainline ZODB. I'd be happy to do it with > Jeremy's approval. (Jeremy, are you reading?) +1, its useful and often requested here. -kapil _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@xxxxxxxx http://lists.zope.org/mailman/listinfo/zodb-dev

Next Message by Date: click to view message preview

Re: [ZODB-Dev] Fwd: directory hierarchy proposal (Martijn Faassen)

Phillip J. Eby wrote: > At 09:52 AM 12/11/02 +0100, Martijn Faassen wrote: > > >Sounds fine to me, but that could apply to other packages in the Zope tree > >too. What about zope.interface, for instance? Not that they're that > >widely used yet, but that's certainly a goal. > > Yikes! I guess I better go back and read that proposal again and complain > some more... I didn't realize Interface was headed that way too. > Could we please *not* move around stuff that's not *in* the Zope package > hierarchy right now? Talk about not being backward compatible... Well, it is going to go lowercase too. :) [snip good points about backwards compatibility] I think the people who are advocating a top level 'zope' package should check in here. The idea as I understand it is that the 'zope' package *will* only contain stuff that is useable outside of Zope. 'zope.app' will contain stuff that is specific to the zope app server itself. This separation is already in effect. > And, if the goal is for Zope 3 to eventually use Zope 2 code, you're > inviting dependencies and incompatibilities to creep in if you mask the > fact that these are supposed to be components that can be separately > distributed and used. Hm. I'm not sure what the status of this goal is. Regards, Martijn

Previous Message by Thread: click to view message preview

Next Message by Thread: click to view message preview

Re: transacting multiple databases

On Wednesday 11 December 2002 6:35 pm, Shane Hathaway wrote: > ... for Zope 3 we should plan to do all "mounting" using cross-database > references. It will be faster and more seamless. There won't be a > "mount point" object that conceals itself; instead, ZODB will just know > to load the mounted object from a different database. Is seamless a good thing? Right now I like the fact that cross-database links are not handled in the lower layers (DB and down) because it means we can have stronger invariants for those layers, such as reference checking. In filesystem terms, today we have a crude equivalent of cross-filesystem symbolic links. I think there is less usefulness in something like a cross-filesystem hard link (which is what I think you are suggesting), rather than a better symbolic link. > OTOH AdaptableStorage provides a very different way to mount data from > multiple sources, and it already works with the current ZODB code. I'll > explain how this works soon. I am looking forward to it. _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@xxxxxxxx http://lists.zope.org/mailman/listinfo/zodb-dev

Loading Comments...