Subject Re: [Firebird-Architect] Metadata locking policy and caching
Author Alex Peshkov
On Wednesday 06 August 2008 15:49, Paul Beach wrote:
> Adriano,
>
> > > I think we are all aware of the issue re.
> > > "We generally see users complaining about old procedure and triggers
> > > versions running even in SS. We point them that this is documented in
> > > IB6 docs."
> > >
> > > As you correctly point out it has been documented for a log time.
> > > At the moment reading this thread I feel that you are using
> > > "a sledgehammer to crack a nut" - if the phrase doesn't make sense I
> > > can explain it.
> >
> > I don't consider documented laziness of designers/programmers as
> > features...
>
> At no point did I suggest it was a feature... just that the engine has
> worked this way for a long time, and I don't think now is the time to
> change it.

No, certainly the fact that old version of procedure is invoked whennew one
should be called is a bug, not feature. But the _ability_ (may be sometimes
not well implemented) to change metadata without full database shutdown is
definitely a feature, and we should fix implementation, not drop it.

> > I will be very happy to see suggestions to:
> > - make easier to do multi-threaded SS

Telling true, last criteria for me.
Optimization of our work is certainly useful thing, but as long as code
written is _useful_ code.

> > - works ok in CS
> > - is consistent (i.e., we know exactly how things works)

BTW, your suggestion to have different rules for different objects does not
add consistency to the cache ...

> > - allow we to add each feature in X time, instead of 1.5X or 2X

Let me add one more:
- does not break existing features, useful to people

I do not want to say that we should never drop old utilities / features (for
example, why not drop GDEF which is almost unused and almost all people do
not know what for it? or may be I'm wrong here?), but in your RFC you've
suggested to drop ability to modify metadata on the fly, which is USED by
people, and used actively. Yes, it makes metadata cache much simpler. But it
also makes it not feature complete.

> > Let me say that we're just discussing things. And my somewhat incomplete
> > RFE was just to see community/project members reaction without loose too
> > much time for nothing.

This is for sure correct approach.
Moreover, it worked this time excellent - currently we can see that suggested
cache does not satisfy project needs.