Subject Re: [Firebird-Architect] Vulcan architecture and lock tables
Author Dmitry Yemanov
Jim Starkey wrote:
>
> What you're saying is that if you go out of your way to screw it up, you
> can screw it up.

Nope, I say that the default setup is screwed up. Do you see the
difference between: "you can change something to break the thing" and
"you must change something to avoid shit from happening"?

> There is no reason for a user to change the lock file name from whatever
> the installation configures. And if the installation configures
> different lock files for incompatible engines, then it works.

But we don't have any installation at all at the moment, so your words
sound like: yes, I've screwed up the thing, but a clever installation
routine (that I didn't care to implement or even document) should solve
that.

Also, you haven't answered what the installation should do with
fb_lock_print.

> Two hours ago you didn't even know the feature existed.

You should start to read other people's messages carefully instead of
dreaming what you'd like to see there.

> If I sound annoyed, I am. I spent a lot of time thinking about it and
> writing about it (on this list) when you weren't willing to even read
> the mail. Now you want to trash it before you even understand it.

Why do you take any critique of the implementation as a personal attack
to your lovely architecture? The point of my message was not to say that
the architecture is crap but to show that it exposes some issues that
requires solving. You could manage to screw up the FB setup the same
way, but it would never happen in the default mode, be it done via the
automatic installer or manual unzipping. This is what I'd like to see in
Vulcan. If you cannot suggest anything useful, then I'll be treating the
feature as potentially dangerous.

> Rather than just giving us your opinion, why don't you critique the
> design. Is there something it doesn't do that it should? Can it be
> extended? Do we understand how it should be administrated? Or you
> might just hint at what you don't like.

I've posted a problem and asked for solutions. You answered that
everything is as designed and nothing should be changed. I'm not
satisfied, sorry. Suggestion of Rick Debay sounds more constructive and
friendly, although it doesn't address the fb_lock_print issue. Also, the
events table has the same problem (although, fortunately, its version is
not changed often).


Dmitry