Subject | Re: [IB-Architect] Re: [IB-Priorities] Isolation level implemetation |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2000-12-28T14:01:04Z |
Hello, Jim!
Jim Starkey wrote:
When Delphi 5 was released, a lot of programmers started to use IBX,
native components. The most hard question was:
I'm changing data, but can't see changes until application restart or
I restart transaction. What is happening?
You know, this "problem" is only because Interbase uses SNAPSHOT
isolation mode by default.
So, to make Interbase use easier, you must tell everybody to doubleclick
on IBTransation and set ReadCommitted mode or write parameters directly
to IBTransaction.Params. Or, you can write FAQ.
But. Don't say "it's their problems". Interbase is developed for people (if I'm wrong,
please correct me).
Another thing - IB 6 uses Forced Write OFF by default. People must set it ON
to eliminate database corruption during OS or hardware failures.
And so on.
I think it is very bad when you tell people - "install my soft, and then do this, that
and another 100 things, and it will work". Look at PostgreSQL or MySQL. You must do
some VERY strange things after installation before server will work.
Also the same things can be said about functionality. "We will not implement
read uncommitted not because it will take us 5 lines of code changes, but
because it is bad to use read uncommitted". "We do not want to implement TOP/LIMIT
because it is bad way to write applications".
Have you looked at MS SQL 7 (or 2000) functionality? It is getting closer and closer
to Interbase functionality!
I remember when in 1995-1997 I was telling people - this is better than in Oracle
and much easier than in MS SQL. But now look at that - Oracle and MS SQL have
automatic growth of database and transaction log. MS SQL 7 have record locking.
Oracle is better in record "versioning". MS SQL's optimizer is very good. And more.
What had changed in Interbase during last 5 years?
If you (we) will reject features that customers ask, next year there will be no reason to use
Interbase instead of MS SQL, PostgreSQL or even MySQL (they are close to implement transactions
in MySQL).
At least every server have CASE in SQL. Interbase will have it in 7.0 version? Too late.
Excuse me, I'm not against you. I'm against such a point of view.
At last, look at Borland. If there were no IBPhoenix/Firebird, we hadn't seen ANY changes.
People staying with Interbase not with Borland, but with you, Ann, Paul and others, the only
ones who can give Interbase good feature. Hope it will not be just a bugfixing.
Anyway <g>, with great pleasure to you and all Interbase community, Happy New Year!
--
Dmitry Kuzmenko, Epsylon Technologies.
Jim Starkey wrote:
> Don't sniff glue 'cause all the other guys do it. Dumb is dumb.Hmm, I want to say one note:
> If they need an underhanded mechanism because their transaction
> control is too expensive to use, well, that's their problem, not
> ours.
When Delphi 5 was released, a lot of programmers started to use IBX,
native components. The most hard question was:
I'm changing data, but can't see changes until application restart or
I restart transaction. What is happening?
You know, this "problem" is only because Interbase uses SNAPSHOT
isolation mode by default.
So, to make Interbase use easier, you must tell everybody to doubleclick
on IBTransation and set ReadCommitted mode or write parameters directly
to IBTransaction.Params. Or, you can write FAQ.
But. Don't say "it's their problems". Interbase is developed for people (if I'm wrong,
please correct me).
Another thing - IB 6 uses Forced Write OFF by default. People must set it ON
to eliminate database corruption during OS or hardware failures.
And so on.
I think it is very bad when you tell people - "install my soft, and then do this, that
and another 100 things, and it will work". Look at PostgreSQL or MySQL. You must do
some VERY strange things after installation before server will work.
Also the same things can be said about functionality. "We will not implement
read uncommitted not because it will take us 5 lines of code changes, but
because it is bad to use read uncommitted". "We do not want to implement TOP/LIMIT
because it is bad way to write applications".
Have you looked at MS SQL 7 (or 2000) functionality? It is getting closer and closer
to Interbase functionality!
I remember when in 1995-1997 I was telling people - this is better than in Oracle
and much easier than in MS SQL. But now look at that - Oracle and MS SQL have
automatic growth of database and transaction log. MS SQL 7 have record locking.
Oracle is better in record "versioning". MS SQL's optimizer is very good. And more.
What had changed in Interbase during last 5 years?
If you (we) will reject features that customers ask, next year there will be no reason to use
Interbase instead of MS SQL, PostgreSQL or even MySQL (they are close to implement transactions
in MySQL).
At least every server have CASE in SQL. Interbase will have it in 7.0 version? Too late.
Excuse me, I'm not against you. I'm against such a point of view.
At last, look at Borland. If there were no IBPhoenix/Firebird, we hadn't seen ANY changes.
People staying with Interbase not with Borland, but with you, Ann, Paul and others, the only
ones who can give Interbase good feature. Hope it will not be just a bugfixing.
Anyway <g>, with great pleasure to you and all Interbase community, Happy New Year!
--
Dmitry Kuzmenko, Epsylon Technologies.