Subject | Re: [Firebird-Architect] Metadata locking policy and caching |
---|---|
Author | Alex Peshkov |
Post date | 2008-08-06T12:46Z |
On Wednesday 06 August 2008 15:49, Paul Beach wrote:
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.
Optimization of our work is certainly useful thing, but as long as code
written is _useful_ code.
add consistency to the cache ...
- 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.
Moreover, it worked this time excellent - currently we can see that suggested
cache does not satisfy project needs.
> Adriano,No, certainly the fact that old version of procedure is invoked whennew one
>
> > > 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.
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:Telling true, last criteria for me.
> > - make easier to do multi-threaded SS
Optimization of our work is certainly useful thing, but as long as code
written is _useful_ code.
> > - works ok in CSBTW, your suggestion to have different rules for different objects does not
> > - is consistent (i.e., we know exactly how things works)
add consistency to the cache ...
> > - allow we to add each feature in X time, instead of 1.5X or 2XLet 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 incompleteThis is for sure correct approach.
> > RFE was just to see community/project members reaction without loose too
> > much time for nothing.
Moreover, it worked this time excellent - currently we can see that suggested
cache does not satisfy project needs.