[Grok-dev] Re: Keeping indexes up to date
faassen at startifact.com
Tue Aug 14 12:22:58 EDT 2007
Philipp von Weitershausen wrote:
> On 13 Aug 2007, at 14:10 , Martijn Faassen wrote:
>> I was not discussing this particular case. In many cases this is going
>> to be fairly easy to accomplish. In other cases it's going to make the
>> developer think quite hard - importing the contents of an object from
>> XML may be an example. Any code that isn't form-driven is going to be
>> an example. We'd be asking people to think extra hard, write more
>> code, and so on, while it likely has *no* effect on their system
>> whatsoever. The catalog indeed *completely* ignores this information.
> Right now it does ignore, but I've tried to write a catalog that
> performs better by NOT ignoring this information (in the end it couldn't
> be done because zope.formlib and others, alas, don't send the info).
Right. Your argument to do this will be stronger once the catalog starts
using this information. How much stronger is debatable - it might not
really gain much performance at all, or might even in some cases *slow*
down the system to do this (as figuring out what changed takes time and
might take more time than is saved in the catalog). The only way to find
out is to do do measurements.
> Also, the catalog is just one possible subscriber. The idea of events is
> that they're a great way to separate concerns. You're making assumptions
> about other concerns by arguing that the information is useless.
I'm not arguing the information is useless under all potential
circumstances. I'm arguing the information is currently not used
anywhere and telling people to send this information is therefore
telling people to do useless work. If a particular code base has
subscribers which can make use of this information, developers should
send this information along, of course. But that's up to the developers
of that code base.
>> This is inviting people to do cargo-cult programming: "yeah, I put
>> this in as I saw it in other code and I have no idea why but it
> Oh please.
Oh please? :)
> This is a matter of documentation. And in the worst case,
> they won't send along the information, so that all subscribers will have
> take their best guess and e.g. rebuild all indexes, UI elements, etc...
Well, currently nothing is documented at all. I think we shouldn't
emphasize this story too much in our documentation, as:
* it's more to explain.
* more mistakes can be made by developers.
* there's currently no point to actually doing so.
Grok is about a shifting of the balance: even if there is a reason to do
some extra work, the drawbacks of doing the extra work may outweigh the
benefits. Pervasive security proxies providing security by default is an
example of a reason to do more work that we decided against. External
explicit configuration is another reason to do more work that we decided
In this case, there are *no* practical benefits. There is no part of the
framework that is helped if we provide this information. I'd therefore
say this is an excellent candidate saying the drawbacks (extra work)
outweigh the gain (potential benefits in the future).
Once a part of the framework actually starts using this information and
it can be demonstrated to have practical benefits, *then* you should
tell people that they may want to start saying explicitly which
attributes changed. You can then tell them why.
You could say "if only everybody did this, we would be able to do cool
* major benefits haven't been convincingly demonstrated yet, at least to me.
* the people who you do convince may end up doing it buggily (as there
is no difference either way). That's not helping the subscriber author,
or the people who send these broken events.
* you'll never get everyone to do it anyway as doing so has an increased
cost above not doing it. Sometimes a small cost, sometimes a larger one.
More information about the Grok-dev