Subject | Re: [firebird-support] Re: Dirty read? |
---|---|
Author | Ann W. Harrison |
Post date | 2004-06-04T21:45:52Z |
At 03:42 PM 6/4/2004, johnsparrowuk wrote:
Seriously, the right answer is to allow longer index keys. And we
will. We would have done it sooner, but some curmudgeon insisted
that there be no significant ODS changes in Firebird 1 and 1.5, and
changing the way indexes work is really an ODS change. The reason
for the rule is that we were learning the code, in many cases learning
about open source, and trying to establish a solid base on which
to build future versions. If we went off in a bad direction and
really screwed something up, users could go back to an earlier
version very simply if it had a common ODS. We've crossed that
boundary. We have two reasonably stable releases and it's time to
fix some of the really aggravating problems - especially index key
size.
Regards,
Ann
>...indexing a varchar (300) field. It's too big to index -Because it's the Mommy, that's why.
> no problem. Write a 'before insert' trigger [that checks for duplicates]
>
>...except that it won't work like an index because it can't see
>uncommitted values... If I could dirty-read this wouldn't be a
>problem. If dirty reading is 'always bad' then how come indexes
>can do it?!?!? grin
Seriously, the right answer is to allow longer index keys. And we
will. We would have done it sooner, but some curmudgeon insisted
that there be no significant ODS changes in Firebird 1 and 1.5, and
changing the way indexes work is really an ODS change. The reason
for the rule is that we were learning the code, in many cases learning
about open source, and trying to establish a solid base on which
to build future versions. If we went off in a bad direction and
really screwed something up, users could go back to an earlier
version very simply if it had a common ODS. We've crossed that
boundary. We have two reasonably stable releases and it's time to
fix some of the really aggravating problems - especially index key
size.
Regards,
Ann