Subject | Re: [Firebird-Architect] Vulcan architecture and lock tables |
---|---|
Author | Jim Starkey |
Post date | 2006-12-15T21:22:49Z |
Dmitry Yemanov wrote:
can screw it up.
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. Sure, you
can break it, particularly if your goal is to break it. If you don't
touch it, it works.
condemning it. Why don't you think about it for a day and come back
with something better than a shoot from the hip opinion.
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.
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.
> Jim Starkey wrote:What you're saying is that if you go out of your way to screw it up, you
>
>>
>> If I remember correctly, the name of the lock file can be specified in
>> the configuration for each engine provider, which should handle the
>> problem quite nicely.
>>
>
> It's the same as specifying the root directory per provider. It does
> work if you get your hands dirty with the configuration. If you don't do
> it, your installation is irrecoverably damaged. And if you just put an
> older provider into your setup (or if you upgrade your previous setup in
> place), then you're in big trouble.
>
can screw it up.
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. Sure, you
can break it, particularly if your goal is to break it. If you don't
touch it, it works.
> I have no problems with this feature for developers and/or experiencedTwo hours ago you didn't even know the feature existed. Now you're
> field testers, but I would not suggest it for end users. Ever.
>
condemning it. Why don't you think about it for a day and come back
with something better than a shoot from the hip opinion.
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.
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.
>
>