|Subject||Re: [IB-Architect] Re: [IB-Priorities] Isolation level implemetation|
> Ah. If we need to have 'dirty read' because other databasesIn that case we already have the checkmark -
> have it, rather than implementing something bad, we could just
> have the parser convert 'dirty read' to 'read committed'. We
> get the checkmark without producing bad data.
current Interbase accepts command
SET TRANSACTION READ UNCOMMITTED
but behaves like ... errr ... I can't remember exactly, something like
SET TRANSACTION READ COMMITTED NO RECORD_VERSION
IMO this behavior is even worse than allowing dirty reads, because
- if somebody get bad data because of using improper feature
(improper isolation level in this case), it is his fault
- if somebody get bad data because database behaves differently
than expected/declared, it is database's fault
As I said, _if_ dirty reads were implemented, I would use it _meaningfuly_.
_Default_ isolation level in IB is _snapshot_, so if somebody
make some extra work to change it, I would expect he/she knows what
he/she is doing.
Or, should we remove Double Precision datatype from IB ?
When improperly used, you can produce bad data too :-)