On Fri, 19 Apr 2002 07:54:42 -0400, Paul Everitt [EMAIL PROTECTED]
wrote:
This pattern applies better when you have a lot of document cataloging
to be done. A separate process can wake up, make a ZEO connection, and
process the queue. I don't think that indexing documents *has* to be a
Yo,
I have been following this thread for quite some time now,
and call me stupid if you must, but why don't you just keep
the data in the session and write it all out when the session
gets cleaned up?
For the original problem (keeping statistics of site usage)
this will be more than enough.
This is a pretty good idea... the default RAM-based storage that is used
for sessions (TemporaryStorage) tries hard to resist conflicts. It is
also nonundoing and does its own reference counting, so it needn't be
packed unless there it contains cyclic datastructures (there is no UI to
pack
ForkedStorage, I like it simply for the coolness of the name. :^)
But it sparked a different kind of idea, leveraging a pattern that might
emerge in Zope 3.
Let's say we had a queue in Zope. We could asynchronously send changes
into the queue. Later, based on some policy (e.g. idle time,
On Wed, 17 Apr 2002 23:01:04 -0400, Chris McDonough
[EMAIL PROTECTED] wrote:
It would be best to make make a dual-mode undoing and nonundoing storage on
a per-object basis. But a half step would be to make it easier to use
mounted storages ala
A dual mode storage, or simply dual storages?
The former as a long-term goal, the latter as a short-term goal. The
proposal I mentioned would make it easier to build tools that allow you
to mount storages.
Storing counter objects *only* in a non-undo storage would be more
pleasant if ZODB
Chris McDonough wrote:
Storing counter objects *only* in a non-undo storage would be more
pleasant if ZODB supported cross-storage object references.
Yup. I don't think this is anywhere on the radar, though...
How hard would they be to add?
cheers,
Chris
On Fri, 19 Apr 2002 08:18:47 -0400, Chris McDonough [EMAIL PROTECTED]
wrote:
Storing counter objects *only* in a non-undo storage would be more
pleasant if ZODB supported cross-storage object references.
Yup. I don't think this is anywhere on the radar, though...
H. cross-storage
Paul Everitt wrote:
Let's say we had a queue in Zope. We could asynchronously send changes
into the queue. Later, based on some policy (e.g. idle time, clock
ticks, etc.), those changes would be enacted/committed.
Imagine the queue itself is in a different storage, likely
CM == Chris McDonough [EMAIL PROTECTED] writes:
Completely agreed. My disagreement is portraying the counter
problem as impossible with the zodb. I think some people, as
evidenced by some of the responses, are willing to live with the
tradeoffs. Other people will find managing a
Jeremy Hylton wrote:
CM == Chris McDonough [EMAIL PROTECTED] writes:
Completely agreed. My disagreement is portraying the counter
problem as impossible with the zodb. I think some people, as
evidenced by some of the responses, are willing to live with the
tradeoffs. Other
Jeremy Hylton wrote:
CM == Chris McDonough [EMAIL PROTECTED] writes:
Completely agreed. My disagreement is portraying the counter
problem as impossible with the zodb. I think some people, as
evidenced by some of the responses, are willing to live with the
tradeoffs. Other
That's only if you do it as a property. It doesn't have to be done that
way. Shane and I discussed a counter that existed as a central
datastructure. Objects that were being counted would simply have
methods to increment the count and display the count.
FWIW, this already mostly exists in
Hi,
How bad are per-request transactions in a non-ZEO environment? I.e.
each request on a folder or its subobjects will cause a write transaction
(somewhat like a non-fs counter, but worse as it happens for all subobjects)
And if this is really bad, are there any workarounds except for writing
This will kill performance, especially concurrent use of the site. It
will also cause large amounts of database bloat. Do you need real time
numbers, or is a delay (such as 24 hours) acceptable?
If you can stand a delay, another approach would be to write a script
which scans the z2.log file
not
create a ZODB transaction.
Hope this helps
Eric
- Original Message -
From: Casey Duncan [EMAIL PROTECTED]
To: Ivo van der Wijk [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, April 16, 2002 10:04 AM
Subject: Re: [Zope-dev] how bad are per-request-write-transactions
16 matches
Mail list logo
