stored in the ZODB. When you update it on one client, it will automatically
be updated on the other clients, as with any other persistent objects.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
to send a query to zodb-dev and zope-dev.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
this refactoring.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
For more information about
callbacks do as little as possible.
Agreed.
This is exactly the model that Zope uses.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
()
FunkyRollbackException
From my point of view I can't see a reason why the ZODB forbids a
second rolback to the savepoint.
I agree. This should be changed.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
there reads like it's OK to roll back to the _same_ savepoint
multiple times (it's not earlier than itself ...).
Yup
But
transaction/savepoint.txt explicitly says (and tests that) you can't, so
it's intended behavior:
Yup, but I think it is incorrect behavior.
Jim
--
Jim Fulton mailto
Jürgen Herrmann wrote:
[ Jim Fulton wrote:]
Jürgen Herrmann wrote:
hi all!
i'm trying to form a patch that will result in a method
_before_commit()
being called on each modified object in a transaction (if that method
exists of course) right before commit.
main sense is to automate/delay
Jürgen Herrmann wrote:
[ Jim Fulton wrote:]
Jürgen Herrmann wrote:
[ Jim Fulton wrote:]
Jürgen Herrmann wrote:
hi all!
i'm trying to form a patch that will result in a method
_before_commit()
being called on each modified object in a transaction (if that method
exists of course) right
._invalidate_all_savepoints()
i.e. swapping the first two blocks]
[Jim Fulton]
subtransactions != savepoints
There is *no* promise of nestability with subtransactions. Committing a
subtransaction invalidates prior savepoints by design. This is necessary
to maintain backward compatibility
it fails, it does so in subtle ways that cause people
to lose lots of time.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
strengthened my opposition.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
For more
.
This is an excellent argument.
+1 on _p_changed=1 deghostifying, if necessary.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
still working on this in my downtime. If anyone else is interested
in helping out, let me know!
Thanks for the work! I'll try to squeeze in some time soon to review the
current
blob code. Where is it?
I'll
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Andreas Jung wrote:
...
Sorry, this is a stupid assumption.
No. It was an incorrect assumption.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
interest to applications. Then applications
can use the event system to be notified and provide additional
functionality.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
documentatoon to be managed with the code.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
/zope/app/generations/README.txt?view=markup
Note that even though this package is in zope.app, the solution is quite
general and should be usable outside of Zope. (This package really should be
lifted up a level.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
?
No.
First, ZODB time stamps are based on UTC time.
Second, time-stamp skew doesn't lead to inconsistency.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
requite
a switch to Twisted. This might be worthwhile, but would almost
certainly entail a lot of risk. I'm not at all sure the benefit
is worth it unless there were some able volunteers who wanted to
work on it.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered
not
the right place to put complexity. If you don't expect to have more than
2**N objects, an oid that requires more than N bits is in some sense
extravagant ;-). In any case, you should be able to use bigger strings
now without changing anything.
Yup.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
Shane Hathaway wrote:
Jim Fulton wrote:
Tim and I have discussed this for some time. We think an
asynchronous I/O approach is still appropriate, to handle
asynchronous messages from servers to clients, but we need
to get away from expecting a server to provide the asyncore
main loop needed
.
It's obviously not just a documentation change.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
of things sooner.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
For more information
Jim Fulton wrote:
Tim Peters wrote:
...
to stop running ZODB tests, no version of ZODB is regularly tested on any
platform anymore; the overnight test runners and buildbot.zope.com
used to
at least test some ZODB versions regularly
Yes, very specific versions, which doesn't help catch
way to integrate data managers into it.
I don't know if the best way to do that is with a base class, or whether a
adapters would be better or ...
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
argument isn't stored because it's always True, at least when
called from outside code. Application code should never pass this
argument. Again, thse arguments are not part of the API.
I'll respond to the original issue separately.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
the database
connection itself. It should call get_connection on an existing connection
and fail if that fails.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
but it
should.
This is just a fossil. Feel free to change it if you wish.
Or to add an entry to the ZODB collector.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
that transaction and ZODB depend on and we'll need to decouple the
transaction exceptions from ZODB.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
required C extensions, I expect source distributions, rather than
eggs will be the norm. Of course, binary eggs for windows and perhaps
some other platforms would be useful.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
and packaged separately.
But that's more work than we want to do now. I do think that persistent
will someday be useful outside of ZODB. In which case, so would BTrees.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
reason,
the ZODB uses jar as a term for a ZODB connection).
This goes back to early BoboPOS versions and is based on the
notion of a pickle jar.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
in saying your messages are
being held for moderation. I am moderating the list. When I see
legitimate held messages, I'll add the sender to the list of valid
non-member senders. So if you don't want to subscribe, you don't have
to. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Jim Fulton wrote:
...
You can do that now. Just start a thread with the main loop.
Note that Zope 3 does this now when the Twisted server is used.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
either 32-bit or 64-bit integers at run-time.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
of iterating over all objects on any
storage?
Absolutely. That has been the plan all along.
The api in FileStorage was just a beginning step toward this.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
networking be independent of
an application. Fortunately, asyncore allows multiple independent main loops.
Does Twisted?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Florent Guillaume wrote:
On 25 Apr 2006, at 15:23, Jim Fulton wrote:
Florent Guillaume wrote:
[Ccing zodb-dev]
On 25 Apr 2006, at 15:09, David Pratt wrote:
The protocol is simple yes, but the iteractions w.r.t threading
are sometimes subtle.
Hi Florent. This could be set up using
Florent Guillaume wrote:
Hi,
Jim Fulton wrote:
Log message for revision 67595:
Added compatibility for old pickles.
Modified:
Zope3/branches/jim-adapter/src/zope/app/component/tests/test_registration.py
+# Work around a bug in ZODB
+# XXX fix ZODB
+class FileStorage
are:
- Whether we want Twisted to be a dependency of ZEO
- Performance
Switching to twisted would be a big change. If I was to make such a
change, which I anticipate, it would be great if twised could be an
option.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
to experiment in zope's svn?
Sure I could. Submit a contributor's ageement and make a branch.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Tim Peters wrote:
[Christian Theune]
Hmm. Sorry, but could you point out where the API is defined? I might
not have looked hard enough. I only found internals to exploit. :(
[Jim Fulton]
I wish I could. I'm almost certain that Chris McDonough implemented
one at PyCon 2005
. The client and it's cache are not
involved. In fact, this has nothing to do with ZEO.,
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
For more information about ZODB, see the ZODB
Tisted's use without requiring it.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
an explicitly stated goal, it's not likely
to happen. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
. I just did a quick scan of the DB and
Connection code and see opportunities like eliminating the
modified-in-version cache, eliminating version-aware object-cache
policies and possibly eliminating connection pools for version data.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
For more information about ZODB, see the ZODB Wiki
Toby Dickenson wrote:
On Sunday 14 May 2006 21:52, Jim Fulton wrote:
Toby, this is almost certainly a question for you. :)
Can someone explain to me why getExtensionMethods is needed in the
storage API? It's not used by anything in ZODB.
ZEO proxies the standard storage API.
Right
d.update(cPickle.loads(ext))
You should report this to Shane.
It's possible that there is a bug in PGStorage in handling
extension data. I can easily believe that Z2 doesn't use extension
data and perhaps z3 does.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered
Chris Withers wrote:
Hi Jim,
Jim Fulton wrote:
BTW, I strongly discourage use of Undo except in emergencies.
Sadly, except when undoing the last (non-undo) transactions in
a database can lead to inconsistency.
What sort of inconsistencies are you referring to?
Logical inconsistencies
Chris Withers wrote:
Jim Fulton wrote:
...
Even if you did track reads, how would you distinguish an unsafe read
as above from a normal read that shouldn't cause a conflict?
A write (or the undo of a write) would conflict with any reads in later
transactions.
Jim
--
Jim Fulton
Chris Withers wrote:
Jim Fulton wrote:
Chris Withers wrote:
Jim Fulton wrote:
Even if you did track reads, how would you distinguish an unsafe
read as above from a normal read that shouldn't cause a conflict?
A write (or the undo of a write) would conflict with any reads in later
of ZRS is that it supports geographic replication.
Your secondaries can be offsite. We will also be adding an option for
remote backups using the ZRS recovery protocol without actually
running a
full-bore secondary. We are starting to use this for some of our
customers
now.
Jim
--
Jim
and client and restart them, does the
problem persist?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com
On Jul 31, 2006, at 3:55 PM, Jim Fulton wrote:
On May 31, 2006, at 4:03 AM, Chris Withers wrote:
Hi All,
I mentioned this before:
File C:\Zope\2.9.2\lib\python\ZEO\cache.py, line 151, in
setLastTid
self.fc.settid(tid)
File C:\Zope\2.9.2\lib\python\ZEO\cache.py, line 1060
On Jun 12, 2006, at 1:35 PM, Dieter Maurer wrote:
Sorry to take so long to get to this
Jim Fulton wrote at 2006-6-12 06:34 -0400:
...
The potential inconsistency occurs because the ZODB (Connection)
cache
may contain objects not in the ZEO client cache. Even if invalid
meanwhile
been found to be a problem?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
On Aug 15, 2006, at 2:32 PM, Jim Fulton wrote:
On Jun 12, 2006, at 1:35 PM, Dieter Maurer wrote:
Sorry to take so long to get to this
Jim Fulton wrote at 2006-6-12 06:34 -0400:
...
The potential inconsistency occurs because the ZODB (Connection)
cache
may contain objects
in ZODB.
Yup
I can put a fake progress indicator
anytime that advances every second a bit and never reaches 100%.
Good idea. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http
On Aug 17, 2006, at 2:52 AM, Chris Withers wrote:
Hi Jim,
Sorry for the delay, was on holiday in Canada...
Jim Fulton wrote:
On May 31, 2006, at 4:03 AM, Chris Withers wrote:
File C:\Zope\2.9.2\lib\python\ZEO\cache.py, line 151, in
setLastTid
self.fc.settid(tid)
File C:\Zope
On Aug 27, 2006, at 9:53 AM, Jim Fulton wrote:
No. Starting in 3.3, ZODB has multi-database support, which made
Zope 2's implementation of mounting much cleaner.
I got confused about version numbers. Multi-databases were
introduced in ZODB 3.6.
Jim
--
Jim Fulton
() result out of range
-
Yeah, especially because I didn't realize we were using protocol 2 yet.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation
/listinfo/zodb-dev
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
to.
If the old index is determined not to be valid, then of course, the
index has
to be rebuild from scratch.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
On Sep 26, 2006, at 2:31 PM, Dieter Maurer wrote:
I would like to make some ZODB enhancements proposals and later
implement them.
Where is the right place to put such proposals?
http://www.zope.org/Wikis/ZODB/FrontPage
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
object modification times.
If we switched to integers, this would break. This isn't to say that we
shouldn't fix this, but doing so would entail some significant disruption.
I would go so far to say that the benefit isn't worth the cost for
FileStorage.
Jim
--
Jim Fulton mailto:[EMAIL
should consider efficient
C implementations when designing these APIs.
2. Provide object size information to the cache for use in it's
functioning.
I wouldn't do much to this proposal until you've had a chance to read
mine. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
Dmitry Vasiliev wrote:
Jim Fulton wrote:
When I originally developed the ZODB, I created a UML model:
http://www.zope.org/Documentation/Developer/Models/ZODB
This provided a fairly thorough and clear documentation of
the ZODB architecture at the time. It still contains useful information
in your
storage file
You would still need to track times, but you could manage
this as transaction meta data, rather than using it as an id.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
implement your sticky attribute at the application level:
def _p_deactivate(self):
if getattr(self, '_p_sticky', False):
return
Persistent._p_deactivate(self)
You could provide any policy you want, without making the policy part
of ZODB.
Jim
--
Jim Fulton
2.4 anticipates this. :)
Dieters's recent proposal, especially
http://www.zope.org/Wikis/ZODB/MemorySizeLimitedCache
spurred me to begin writing these ideas down. My proposal is an
alternative to the first part of Dieter's proposal.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:10 -0400:
...
I'm a little uneasy about baking this policy so deeply into
the infrastructure. I wonder if the use case can be handled
another way.
A persistent object can override _p_deactivate. For example:
def _p_deactivate(self
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:21 -0400:
...
We would have a use case for this, too.
We've started moving toward just using a single application thread per process
(with many processes). There isn't really much advantage in running multiple
threads if you have multiple
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 15:08 -0400:
...
You could implement your sticky attribute at the application level:
def _p_deactivate(self):
if getattr(self, '_p_sticky', False):
return
Persistent._p_deactivate(self)
You could provide any
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:21 -0400:
...
We would have a use case for this, too.
We've started moving toward just using a single application thread
per process
(with many processes
this where there *is* a benefit
to having multiple threads *and* you have a lot of read-only
data, then I agree that there would be a benefit to sharing
the data. Of course, then you have to deal with thread-safety
issues that you don't normally have in a ZODB application.
Jim
--
Jim Fulton
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 16:18 -0400:
Dieter Maurer wrote:
...
...
We abused Zope a bit and have build a desktop application with it.
One of the main critiques of our customers is too high memory
consumption. Many have computers with 256 MB memory
Chris Withers wrote:
Jim Fulton wrote:
- I wonder if an argument could be made than we shouldn't
implicitly deactivate an object that has been accessed in a
a transaction while the transaction is still running.
Would this prevent ZODB from ever promising not to use more than a
certain
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 16:55 -0400:
...
As explained in the proposal:
We have 3 use cases for volatile attributes:
I didn't ask why you use volatile attributes.
I asked why _p_sticky needs to be stored on each instance,
since it is set at the class level
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 17:04 -0400:
...
Or consider object activation and deactivation. If a ghost is
shared among multiple threads, then __setstate__ could
be called from separate threads.
But, why should this be a problem? They would install the same
state
, as it on windows makes it highly likely that data will not be
written to disk at all, and a crash could quite likely make you loose
all your changes.
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
include a message to the server
indicating that this transaction is not precious.
Nah, too subtle/fragile/complicated...
...that's my gut feel anyway.
I really like the proposal as it stands though :-)
Agreed.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
:
http://www.zope.org/Wikis/ZODB/FrontPage
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
the
release with zc.buildout.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
For more
.
Sorry for the confusion.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
in advance,
Matthew
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
--
Jim Fulton mailto:[EMAIL
.
There is no test currently assuring this or the opposite. Once I
find out, I'll update the tests.
At this point, I don't really remember many details.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
Chris Withers wrote:
Jim Fulton wrote:
...
Of course, there's also the blob work.
Not sure how this relates to persistent zeo client caches...
It doesn't. It was in response to your statement:
zodb doesn't seem to have gotten that much attention since 2.9.x, unless I've
missed
work but it does not appear to in ZODB 3.6.
DemoStorage does (or should) support undo.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp
. In fact, I'l be happy to see this code get ripped
out. If it stays in it needs a doctest to prevent future regression
and to explain how to use it, including what it's semantics and
limitations are.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
On Jan 30, 2007, at 11:12 AM, Philipp von Weitershausen wrote:
Jim Fulton wrote:
On Jan 29, 2007, at 5:46 PM, Philipp von Weitershausen wrote:
After refreshing a product, Zope 2 uses the following stanza in
App.RefreshFuncs.autoRefresh() to let the ZODB know that it
should invalidate its
90MB records lead to memory errors
even on machines with a hundreds of megabytes free.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation
I'd like to have a get together at PyCon on Saturday night at 8pm:
http://us.pycon.org/TX2007/ZopeObjectDatabaseBoF
If you are interested please add your name to the BoF page.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO
/mailman/listinfo/zodb-dev
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
On Feb 25, 2007, at 9:09 AM, Christian Theune wrote:
No, just create a new project. This doesn't have to be in the core
ZODB.
Storages can be defined in new python packages. Why don't you try
'z3c.tracingstorage'?
Excellent point,
Jim
--
Jim Fulton mailto:[EMAIL
sense tells you not to.
- George Seaton
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
--
Jim Fulton
- The wiki is editable by anonymous users and we rely on it to find
download files. This looks like a security risk.
Good point. Feel free to make it so, or I will later.
Thanks.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO
On Feb 28, 2007, at 9:23 AM, Christian Theune wrote:
Am Mittwoch, den 28.02.2007, 09:19 -0600 schrieb Jim Fulton:
On Feb 28, 2007, at 8:55 AM, Christian Theune wrote:
Hi,
at the sprint we've discovered that the PyPI entry points to the
wiki
page of ZODB. This seems to be a bad idea
I've released release candidate 1 of ZODB 3.7 to PyPI:
http://www.python.org/pypi/ZODB3/3.7.0c1
If there are no objections, I'll make the final release in a few days.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO
1 - 100 of 773 matches
Mail list logo
