[ZODB-Dev] SpatialIndex

[Laurence Rowe]

On 28 June 2010 15:23, Nitro <nitro at dr-code.org> wrote:
> Am 28.06.2010, 14:10 Uhr, schrieb Dylan Jay <djay at pretaweb.com>:
>
>> I don't use a lot of other indexes other than what comes with plone but
>> I can see the value of what your suggesting in having an installable
>> tested collection of indexes. I can also see that this is a really big
>> itch for you and you've already identified a bunch of candidates to
>> include. So why not go the next step and create a package that's nothing
>> more than requires specifications and release it with versions
>> corresponding to zodb releases. Then others may find it useful and help
>> you support it. And if it's really popular it may even get taken into
>> consideration with zodb packaging. Who knows?
>
> Thanks for your feedback, Dylan.
>
> My main problem is not the lack of an index collection. It's one of the
> problems I faced, but not the main one. Indexing is just a small part of
> working with a database.
>
> The main problem (imo) is that there are already >50 zodb related packages
> on pypi and none of them gathered a lot of people working on them. I don't
> see why this should be any different if I publish yet another package.
> Especially if most people use plone and the built-in indices. Just look at
> what happened to ZCatalog Standalone.
>
> Here's a little metaphor for what I'm trying to say:
>
> Once upon a time there was a man who wanted to go to the bakery to buy a
> bread. He thought "I'll be done with this quickly, after all many people
> want to buy a bread". So he went off to visit the ZBakery.
> When asking for a bread, the people in the ZBakery told him there's no
> need to sell whole breads. They said: "See, we have all the ingredients
> here so you can make a bread suiting your own taste. Look, there's ZFlour,
> ZMilk and ZSalt. And if you rummage the corners of this bakery, you'll
> also might find ZFlour2, CustomFlour and MyOwnCoolFlour. We don't know if
> they are any good, because each flour is used by just one or two people.".
> The man thought about it for a while and went off to try the different
> flours. When he wanted to try the CustomFlour it did not work. It turned
> out this was because CustomFlour relied on 3rdPartyMill and 3rdPartyMill
> had a problem, so CustomFlour was broken. The man shaked his head after he
> realized a few dozen people already tried to get CustomFlour and nobody
> pointed out the problem to its producer. Finding out about all of this
> took the whole morning and so he finally made lunch break.
> After his lunch break was over he finally found a flour suiting his bread
> he went off to look at the different milks and salts. He experienced
> similar problems there. One of the milks had just a label "milk" on it,
> the other areas of the packaging were blank. The man had no idea if the
> milk in question would work for his bread or not. So he had to analyze the
> contents of the milk to see if it might be useful. It turned out the milk
> was mislabeled and not a milk.
> As the sun was already touching the horizon and the air was getting cold
> the man ignored the milk for the time being and went looking for salt. He
> did not have to search for long and was delighted to find a single salt
> which would just work.
> When the man looked out of a window of the ZBakery he saw it was already
> dark and went home. When lying in bed he thought to himself: "All I wanted
> to have this morning was a bread. Now I'm about to fall asleep and still
> don't have one. The bakery even had all the ingredients! But why did they
> made me try and analyze each ingredient? I even would've taken a bread
> which tasted a bit worse then the bread which I now have to bake on my
> own. The other customers of ZBakery surely also want breads, rolls and
> cake. Aren't they interested in creating a standard package of breads,
> rolls and cake? If they'd work together on a single bread, they'd all
> benefit from the improved recipes. New customers would immediately notice
> that there's a good default bread which many people like. These customers
> might point their colleagues at ZBakery, because it sells tasty,
> ready-to-use breads. If there was a special customer he could still bake
> his own bread using the individual ingredients."
> Pondering all these things he slided into a deep sleep. When he woke up
> the next morning he found a handful of committed people who had gathered
> in the ZBakery to bake and sell their first bread together...

There are some valid criticisms in here. One problem with PyPI is that
there is no way to clearly mark a package as having been superseded,
as zc.relationship was by zc.relation.

So why don't we all work on the same packages? The main reason is one
of legacy. Plone is built on Zope2 and ZCatalog. It works, but it is
not without it's issues - we can't have queries that join from that
catalog to a zc.relation catalog. Standalone ZCatalog failed because
it came to early - Zope2 was only recently eggified, so to be
successful the standalone ZCatalog would need to be used in Zope2.
Nobody has bothered with this because non-legacy code shouldn't be
using ZCatalog anyway - there are newer and better ways of doing it.

I'm sure the ZODB documentation project
(http://zodbdocs.blogspot.com/) would gladly accept a contribution
towards clarifying what current best practice is for catalogs in ZODB.

Whether you release your code as a package or not is really up to you,
but I strongly suggest you do if you have any interest in other people
using and contributing to that work.

Laurence