Shane Hathaway wrote:
http://dev.zope.org/Wikis/DevSite/Proposals/BetterTracebacks
All the work described (besides the documentation and Dieter's suggestion
of adding error_tb to the default standard_error_message) is checked into
the trunk. No more invalid HTML. :-)
Well, it's only
Anthony Baxter wrote:
deliberately-trolling-for-ChrisW-ly yrs,
:-P
Chris - stay in the stone age, I hear they have fire there ;-)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or
Chris McDonough wrote:
It would be best to make make a dual-mode undoing and nonundoing storage on
a per-object basis.
...if anyone achieves this, I will have plenty of beer to send to them.
Chris - please, pretty please :-)
___
Zope-Dev
Chris - stay in the stone age, I hear they have fire there ;-)
mmm. fre pretty.
Page Templates burn, don't dey. Be a shame if somefing was to happen
to your nice shiny website.
Anthony, who might have been spending too long in the bad places of SQL.
Anthony Baxter wrote:
Anthony, who might have been spending too long in the bad places of SQL.
Maybe getting hooked back on the PHP too? I saw ya, that dodgy bloke in the
street, money changing hands...
*grinz*
Chris
___
Zope-Dev maillist -
Hello Brian.
* Brian Lloyd [EMAIL PROTECTED] [2002-04-17 20:29]:
Ok. I'd like to run the mbox thing by Jim to see if he has any
The product now uses a Maildir-style approach to deal with
concurrent writes. The creation of the file name uses
time(), gethostname() and randint() to hopefully
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
Toby Dickenson [EMAIL PROTECTED] wrote:
Whenever a write comes in at the over-ten-second mark,
you write the _v_ attribute to the persistent attribute.
That would be bad. _v_ attributes are lost when the object is
deactivated and removed from the ZODB memory cache It would lose
the
Florent Guillaume wrote:
Or am I misunderstanding something ? My question really relates to any
use of _v_ as a cache that can survive on publisher transaction, really.
Should _v_ never be used like that ?
There's a case to be made for attributes that not persisted (like _v_
attributes)
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
On Thu, 18 Apr 2002 16:23:15 + (UTC), Florent Guillaume
[EMAIL PROTECTED] wrote:
This reminds me of a question I had: given that (from what I understand)
_v_ attributes only live in the object cache of a given Zope,
True, and more accurate that I think you expected
The issue is that
Ive never looked at LDAPUserFolder so this may be irrelevant, but is
it possible for LDAPUserFolder to validate that the cached _v_
information is still fresh? If that validation is quicker than
fetching a new copy then this is still an overall win.
yes it does have a very rough way of
Toby Dickenson [EMAIL PROTECTED] wrote:
This reminds me of a question I had: given that (from what I understand)
_v_ attributes only live in the object cache of a given Zope,
True, and more accurate that I think you expected
The issue is that one Zope has more than one ZODB object
Max Slimmer writes:
I have created a zclass and want to create a new instance of this class and
have it be child of some other know object in the tree.
Given that we know the path (url) to the new prospective parent how do we do
this.
You locate the destination object with
15 matches
Mail list logo
