On Tuesday 05 August 2008 16:20, Adriano dos Santos Fernandes wrote:

> Alex Peshkov escreveu:
> > Hmmm...
> > Looks like that it means that procedure (and any other object in use) can
> > never be modified from other connection / transaction? If I'm not
> > mistaken with it, too many users will start crying 'regresion!!!' after
> > this change. Specially when we provide connection/transaction independent
> > cache of prepared statements.
> >
> > Remember, we had to re-enable modification of procedure in use in next
> > support release version after it was disabled? I do not want to step on
> > it once more. ........
>
> That's true, but it's why I proposed MON$ extensions.

Imagine SQL batch, doing some metadata changes. Will you suggest people to
analyze MON$ tables before actually changing something?

> Anyway, my work didn't progressed too much on the missing parts (cyclic
> dependencies and multiple DDL in the same transaction). I'm now
> experiment changing procedure DDL logic to DdlNodes, changing system
> tables before start DSQL compilation.
>
> And then I need to insist on isc_ddl deprecation (remove it in V3.0).
> Changing DDL logic to DdlNodes (making parser OO-friendly and DDL
> changes much more simple) is not very difficult, but construct parser
> nodes from DYN codes seems very difficult task.

And moreover - very useless task.

> Maintain parallel DYN
> handling is also far from ideal.
>
> To not make the (few) users doing DDL changes with GPRE very unhappy, we
> may introduce EXECUTE STATEMENT in GPRE. What you think?

Good solution, and should work. But what to do with gdef? It's still used by
TCS (very active), and I'm afraid can be used by some people.

> >> Thoughts?
> >
> > Another idea, how to make metadata cacge work better. Imagine that we
> > have versions of the objects in the cache. A correct version of the
> > object is searched for according to VIO rules. This can let us have full
> > support of transactions in DSQL and not limit users with modification of
> > only unused objects. I.e. when object is modified, previous version of it
> > remains available for all transactions, started before it's committed.
> >
> > Certainly, it seems to be harder to implement compared with your
> > suggestion. But I think it will provide us a lot of benefits in the
> > future.
>
> I think it's very hard to implement

What about _very_ hard - not sure. Certainly not trivial.

> is not generally desired
> functionality,

Not agreed. Full DDL transactions support and ability to modify metadata on
the fly are both desired. 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.

> When one founds a bug in a procedure, he fixes it and the fix may need
> data changes (caused by previously bugged code). Maintaining others
> running obsolete code may be a very bad thing.

Ideally SUCH fix (when you need to correct data broken by previously bugged
code) requires database operations to be stopped. And this is quite the case
when suggested MON$ tables can help much if one does not want to stop access
to DB compeletely (for example, revoking access to that procedure and killing
every request / prepared statement, using it). But I do not see how is it
related with smarter metadata cache.

Have you ever seen a bug report, that use of old copy of procedure (in CS, for
example) caused problems when new one existed? I do not. Generally, we have
the following opportunities:
1. Let old transactions continue using old versions.
2. Do not let modify any object, used in any other running request
(transaction, prepared statement, etc.).
3. Kill and unwind any request, using an object we want to modify (BTW, ideal
when related data changes are needed).
Certainly, both 1 and 3 are easier to implement, and they provide somewhat
stricter logic. But I'm sure users will not like any of it.