On Thu, 31 May 2001 10:36:55 -0400 (EDT), Shane Hathaway
<[EMAIL PROTECTED]> wrote:
>On Thu, 31 May 2001, Toby Dickenson wrote:
>
>> On Thu, 31 May 2001 10:03:31 -0400 (EDT), Shane Hathaway
>> <[EMAIL PROTECTED]> wrote:
>> >Right now ZCatalog randomly generates ConflictErrors even if there are no
Hello everyone,
after I got finally frustrated enough with the current implementation of
the Zope DateTime module, I decided to write a wrapper for mxDateTime. I
checked the license, and the eGenix Public License is GPL compatible, so
that we can use it for Zope now. For more details, see
htt
My last post didnt make much sense. This time ill include all the
words in my sentence
> Large catalog
>updates (where every object is reindexed) also generate a lot of
>conflicts.
Is that last bit true? I thought 'Update Catalog' created *new*
indexes. There might be a conflict on the root
> Thanks Christian, but it didn't work. I went with the long way:
>
>
>
> Valid response
>
> False response
>
>
> False response
>
Valid Response
Fasle Response
cheers,
Chris
___
Zop
- Original Message -
From: "ender" <[EMAIL PROTECTED]>
To: "Andreas Jung" <[EMAIL PROTECTED]>
Cc: "zope-dev" <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 5:30 PM
Subject: Re: [Zope-dev] Request for a Pluggin Index (NameIndex)
> On Monday 04 June 2001 16:55, Andreas Jung wrote:
> >
On Thursday 07 June 2001 07:43, Toby Dickenson wrote:
> > Large catalog
> >updates (where every object is reindexed) also generate a lot of
> >conflicts.
>
> Is that last bit true? I thought 'Update Catalog' created *new*
> indexes. There might be a conflict on the root catalog object, but
> not o
Shane Hathaway wrote:
>
> But I think I have a solution for all of the issues in conflict
> resolution. If you, or anyone else, is also interested in this, please
> show support (if only by saying "please do this"!) :-) I can't work on
> it unless I have a reason to.
Please do this! :-)
I'm p
>We at one point were fiddling with mx from eegenix, for psycopgDA. We found
>out the hard way that the mx.h headers in the DateTime were being put in a
>funny place. Perhaps that may give you a clue.
I hope you are going to use mxDateTime for a new PostGreSQL DA. This would
be for me the MAIN
Hi zopistas,
I currently work on a PythonProduct called JobManager.
The purpose of this Product is, that one can define a hierachical set of
PythonScripts (Jobs with SubJobs)
that are executed in seperate Threads by call or scheduled.
This is intended for use with expensive Database-Update or m
At 10:28 AM 6/7/01 -0400, Chris McDonough wrote:
>Actually, it's good that the license is BSDish, that means that it's
>legally possible to include mxDateTime inside a Zope distribution.
Cool, so the license problem is definitely solved.
Now, we just have to get rid of the last technical issues.
I think using mxDateTime would be a great idea (it would mean DC would
no longer need to maintain our own DateTime module). And since you've
done a lot of good work in creating a wrapper, we've got a head start.
But I think before it can go in to any release, we need to follow the
fishbowl proce
On Thu, 7 Jun 2001, Shane Hathaway wrote:
> It really doesn't matter how many conflicts there are. Within a
> single transaction, 1 conflict is as bad as 100.
Why?
> But I think I have a solution for all of the issues in conflict
> resolution.
Whee!
> If you, or anyone else, is also inter
Me too! Me too!
John
On Thursday 07 June 2001 08:49, Chris Withers wrote:
> Shane Hathaway wrote:
> > But I think I have a solution for all of the issues in conflict
> > resolution. If you, or anyone else, is also interested in this, please
> > show support (if only by saying "please do this"!)
At 11:21 AM 6/7/01 -0400, Chris McDonough wrote:
>I think using mxDateTime would be a great idea (it would mean DC would
>no longer need to maintain our own DateTime module). And since you've
>done a lot of good work in creating a wrapper, we've got a head start.
>But I think before it can go in
At 09:34 AM 6/7/01 -0400, Shane Hathaway wrote:
>
>One thing I didn't make clear in the proposal is that I'm interested in
>repurposing ZCatalog as a general ZODB indexing mechanism and
>essentially moving it down from the application layer to the database
>layer. Catalogs would be updated aut
Hello everyone,
in my development of making SmartObjects a reality, I have implemented the
'isVolatile' attribute into DBObjects. If an object is volatile, it is not
saved in the ZODB, but is created on run time. Thanks a lot Jonathan;
without LocalFS as my template I could have not done it!
--On Thursday, June 07, 2001 09:34:54 AM -0400 Shane Hathaway
<[EMAIL PROTECTED]> wrote:
> But I think I have a solution for all of the issues in conflict
> resolution. If you, or anyone else, is also interested in this, please
> show support (if only by saying "please do this"!) :-) I can't
--On Wednesday, June 06, 2001 11:50:43 AM -0700 jimbo
<[EMAIL PROTECTED]> wrote:
> I hope this helps. I wanted to add my feelings on the whole documentation
> issue. It seems to me that the whole process caters around developers
> too much.
I have to disagree with you **in the context of thi
hello again ...
Okay ... I admit using opera and enjoying it.
Problem is, that opera is sooo standardsconform.
See Zope/lib/python/Products/OFSP/Version.py:175
in function enter()
Somebody thats the path for the cookie as SCRIPT_NAME.
This seems that the scope of the versions should be
limited
On Thursday 07 June 2001 11:51, Erik Enge wrote:
> On Thu, 7 Jun 2001, Shane Hathaway wrote:
> > It really doesn't matter how many conflicts there are. Within a
> > single transaction, 1 conflict is as bad as 100.
>
> Why?
Because in Zope it means the whole request is processed again (which
can
On Thursday 07 June 2001 12:17, Phillip J. Eby wrote:
> At 09:34 AM 6/7/01 -0400, Shane Hathaway wrote:
> >One thing I didn't make clear in the proposal is that I'm interested
> > in repurposing ZCatalog as a general ZODB indexing mechanism and
> > essentially moving it down from the application l
At 02:07 PM 6/7/01 -0400, Shane Hathaway wrote:
>On Thursday 07 June 2001 12:17, Phillip J. Eby wrote:
>
>> The
>> only catch was that this would still produce conflicts at the head
>> end of the linked list. :( Of course, that was in the days before
>> ZODB conflict resolution. Nowadays, you c
i am encountering some rather bizarre problems with 'properties' on
xt_objects, which are effectively fancy folderish DTML Documents.
the problems are two fold...
- i call manage_changeProperties on an xt_object within other xt_objects,
and at times, it would change the same property, e.g. xt_op
Hi,
If I change one property on, say, a DTML Document, does that store a whole
new copy of the document in the ZODB?
If not, then how are properties stored?
Is so, then how about storing properties in their own mini-class that just
subclassed Persistent, so each property got its own pickle jar?
"Phillip J. Eby" wrote:
> That is, in ZPatterns one can specify triggers such as:
>
> WHEN OBJECT DELETED, CHANGED CALL
> someCatalog.manage_uncatalog(self.absolute_url(1))
> WHEN OBJECT ADDED, CHANGED CALL
> someCatalog.manage_catalog(self,self.absolute_url(1))
After I read this again I realize
On Wed, 6 Jun 2001, jimbo wrote:
> I believe that if you are a true developer you will/can figure out the api given
>the vast information available today.
> For example the dcworkflow product was just released. I believe the best
>documentation would be how-to actually use the product.
Ah,
On Thu, 7 Jun 2001, Phillip J. Eby wrote:
> >I was thinking that certain types of objects would be committed by the
> >transaction manager before all others. In this case, the catalog (or a
> >special object in the catalog) would be committed first. It would
> >resolve all conflicts in the cont
At 09:29 PM 6/7/01 +0100, Chris Withers wrote:
>
>If I change one property on, say, a DTML Document, does that store a whole
>new copy of the document in the ZODB?
It updates the object in the ZODB. Whether that causes a copy to be made,
depends on the underlying storage. FileStorage makes copi
Feel free to review and comment the propsal to replace
the current DateTime module of Zope by the mxDateTime module:
http://dev.zope.org/Wikis/DevSite/Proposals/ReplacingDateTime
Cheers,
Andreas
Digitial Creations
___
Zope-Dev maillist - [EMAIL
Description
DCOracle2 is a Python binding to Oracle 8.
DCOracle2 is a replacement for DCOracle, written primarily
in C. DCOracle 1 uses OCI 7 bindings for most Oracle calls,
with OCI 8 mixed in for LOB support. Oracle 8i disallows
mixing of calls within a statement, and so breaks LOB
support. DC
At 07:07 PM 6/7/01 -0400, Shane Hathaway wrote:
>"Phillip J. Eby" wrote:
>> That is, in ZPatterns one can specify triggers such as:
>>
>> WHEN OBJECT DELETED, CHANGED CALL
>> someCatalog.manage_uncatalog(self.absolute_url(1))
>> WHEN OBJECT ADDED, CHANGED CALL
>> someCatalog.manage_catalog(self,s
Hey thanks. That works.
-Original Message-
From: Chris Withers [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 07, 2001 4:43 AM
To: Jeff Nielsen / UgoFast
Cc: Christian Theune; Zope-Dev@Zope. Org
Subject: Re: [Zope-dev] A simple dtml-if question...
> Thanks Christian, but it didn't work
Stephan Richter wrote:
>
> Hello everyone,
>
> after I got finally frustrated enough with the current implementation of
> the Zope DateTime module, I decided to write a wrapper for mxDateTime. I
> checked the license, and the eGenix Public License is GPL compatible, so
> that we can use it for Z
>What does being GPL compatible have to do with Zope ?
>Have I missed some licence changes/discussion ?
Originally mxDateTime was not completely open. This was earlier on a
problem, if we wanted to use it for Zope. But now, we can do this. So I
just wanted to make the point that mxDateTime is
Actually, it's good that the license is BSDish, that means that it's
legally possible to include mxDateTime inside a Zope distribution.
Stephan Richter wrote:
>
> >What does being GPL compatible have to do with Zope ?
> >Have I missed some licence changes/discussion ?
>
> Originally mxDateTime
35 matches
Mail list logo
