Alex Peshkov escreveu:

> We may drop prepared statements cache on commit of DDL transaction. This is
> not more then minor performance issue, it's just a cache. BTW, same could be
> applicable for metadata cache, but I'm afraid we already have some direct
> references to it...
>

Versioned metadata may (who knows, before investigation of how this all
will work with relations, check constraints, computed expressions, etc?)
but don't solve metadata integrity checks. When you're compiling a
object that uses old version of dependencies, fresh dependencies may not
be compatible (number of procedure parameters, for example) anymore. I
see no good way to solve it without locks.

>
>>> Engine should better track versions itself instead
>>> of suggesting people to do it manually using selects from MON$ system
>>> tables.
>>>
>>>
>>>> and not work in some conditions.
>>>>
>>>> When you have table changes, versions doesn't apply. Why one wants to
>>>> update an already dropped column?
>>>>
>>> If transaction was started before column was dropped, it must see it.
>>>
>> Ok. For tables, lock rules may be less restrictive.
>>
>
> Adriano, you start to invent different rules for different objects. Not good
> for me.
>

Not different rules, I want to say that locks may be done on columns
too. But may create a lot of lock objects.

> Please take into an account that this is VERY SERIOUS change in firebird
> behaviour - since interbase days metadata modification was possible in
> parallel with use of that objects. I'm sure that it will create a wave of
> problems for our users not smaller than ones related with changes like
> SQL-standard "NOT IN" or inability to use BLOBs in "SELECT DISTINCT". I will
> be very happy to see a solution of MT-safe, clear, simple to program, etc.
> metadata cache. But I do not like when it breaks logic and features which
> existed for years.

I agree except about "logic". Current behavior doesn't have too much
logic. :-)


Adriano