Subject | Re: [Firebird-Architect] Vulcan architecture and lock tables |
---|---|
Author | Dmitry Yemanov |
Post date | 2006-12-16T06:35:06Z |
Jim Starkey wrote:
difference between: "you can change something to break the thing" and
"you must change something to avoid shit from happening"?
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.
dreaming what you'd like to see there.
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.
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
>Nope, I say that the default setup is screwed up. Do you see the
> What you're saying is that if you go out of your way to screw it up, you
> can screw it up.
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 whateverBut we don't have any installation at all at the moment, so your words
> the installation configures. And if the installation configures
> different lock files for incompatible engines, then it works.
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 andWhy do you take any critique of the implementation as a personal attack
> 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.
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 theI've posted a problem and asked for solutions. You answered that
> 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.
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