On Aug 27, 2005, at 6:08 AM, Wichert Akkerman wrote:
Previously Gary Poster wrote:
We have at least three maintained and capable ZODB backends, with
different strengths and weaknesses, appropriate for different use
cases. Lets not jump to discard any of them.
With current filesystem dev
Previously Gary Poster wrote:
> We have at least three maintained and capable ZODB backends, with
> different strengths and weaknesses, appropriate for different use
> cases. Lets not jump to discard any of them.
With current filesystem developments it might be interesting to try
and use more f
This is a general reply, Martijn just summed up many of the points so
nicely (as usual) that I'm using his email as a starting point...
> From: Martijn Faassen <[EMAIL PROTECTED]>
> Subject: Re: [Zope3-dev] Florent's O-R blog entry
> I have had some opportunity to wor
Martijn Faassen wrote at 2005-8-24 12:27 +0200:
> ...
>Underfeatured query API
>---
>
>I do think that currently the API to query it is woefully underfeatured.
>
>I've tried to work on this problem and am sitting on some code that just
>needs a bit of time to polish and release
Martijn Faassen wrote at 2005-8-24 17:28 +0200:
> ...
>In your example you haven't done a join as I describe above, unless I
>miss something. The essential part is that I want an object with state
>'PUBLISHED' unless there is another object where field 'ID' is the same
>as this object that is wi
Am 24.08.2005 um 18:02 schrieb Martijn Faassen:
Yes, this is bringing the transparency a step further. Basically
what you'd be doing is building an object relational abstraction
based on the Zope catalog. :)
Interestingly the discussion has gone from a general concern of the
usage of RDB
Gary Poster wrote:
On Aug 24, 2005, at 6:27 AM, Martijn Faassen wrote:
[snip]
Now as to where I see areas where features are lacking in the Zope 3
catalog:
Underfeatured query API
---
[snip query API discussion]
Another way of looking at this--or simply an additional f
En/na [EMAIL PROTECTED] ha escrit:
Martijn Faassen wrote:
Missing powerful query concepts
---
Certain powerful query concepts like joins, available in a relational
setting, are missing. I've already run into a scenario where I wanted to
someting like this: given
Paul Winkler wrote:
Martijn Faassen wrote:
Missing powerful query concepts
---
Certain powerful query concepts like joins, available in a relational
setting, are missing. I've already run into a scenario where I wanted to
someting like this: given a bunch of version
On 8/24/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> Hopefully you can see where I would get my interpretation, though.
Yup.
> ZODB catalog story has compelling advantages over an RDBMS catalog,
> in addition to disadvantages.
I'm sure they do, although I'm not immediately aware of them (I would
On Aug 24, 2005, at 8:08 AM, Lennart Regebro wrote:
I'm not convinced that Florent blog entry says what Gary thinks it
does,
Hopefully you can see where I would get my interpretation, though.
I'm happy to have Florent clarify on his return. This is a good
discussion in any case.
but
On Aug 24, 2005, at 6:27 AM, Martijn Faassen wrote:
Hi there,
A few contributions to this interesting discussion...
[snip the Zope 3 catalog is not a hack, and clean and simple]
The catalog and index code is not a hack, and is in fact simple,
effective and flexible. Python is the query
Martijn Faassen wrote:
> Missing powerful query concepts
> ---
>
> Certain powerful query concepts like joins, available in a relational
> setting, are missing. I've already run into a scenario where I wanted to
> someting like this: given a bunch of version objects wit
On Aug 23, 2005, at 3:44 PM, Janko Hauser wrote:
Am 23.08.2005 um 20:36 schrieb Shane Hathaway:
Gary Poster wrote:
On Aug 23, 2005, at 1:11 PM, Gary Poster wrote:
Argh, communication. That still could be too-easily
misinterpreted, and I didn't stare at it long enough before I
sent
I'm not convinced that Florent blog entry says what Gary thinks it
does, but I agree with Gary on the other stuff: It should be possible
by configuration, to switch out at least some parts to a relational
database.
The catalog indexes and metadata is a prime example of this. No, there
is nothing w
Hi there,
A few contributions to this interesting discussion...
[snip the Zope 3 catalog is not a hack, and clean and simple]
The catalog and index code is not a hack, and is in fact simple,
effective and flexible. Python is the query language, and the lack of
an optimizer is not a reason
Am 23.08.2005 um 20:36 schrieb Shane Hathaway:
Gary Poster wrote:
On Aug 23, 2005, at 1:11 PM, Gary Poster wrote:
Argh, communication. That still could be too-easily
misinterpreted, and I didn't stare at it long enough before I
sent it. One more try.
Meanwhile, deciding that a communi
Gary Poster wrote:
On Aug 23, 2005, at 1:11 PM, Gary Poster wrote:
FWIW, my concluding sentence would have been better written as
"Meanwhile, deciding that a community project require an O/R back end
over FileStorage or DirectoryStorage, as Florent argues, feels like a
significant case of
On Aug 23, 2005, at 1:11 PM, Gary Poster wrote:
FWIW, my concluding sentence would have been better written as
"Meanwhile, deciding that a community project require an O/R back
end over FileStorage or DirectoryStorage, as Florent argues, feels
like a significant case of "throwing the baby o
On Aug 23, 2005, at 12:56 PM, Shane Hathaway wrote:
Gary Poster wrote:
In conclusion, the nebulous concept of "enterprise" applications
on Zope does not have a clear cut decision for or against an O/R
mapper such as Ape. The cost of O/R mappings is not
inconsequential, and the advant
Gary Poster wrote:
In conclusion, the nebulous concept of "enterprise" applications on
Zope does not have a clear cut decision for or against an O/R mapper
such as Ape. The cost of O/R mappings is not inconsequential, and the
advantages are not conclusive. I hope that large projects that
21 matches
Mail list logo
