Subject | Re: [Firebird-Java] Re: Unsuccessful metadata update - Solution |
---|---|
Author | Jim Starkey |
Post date | 2005-06-25T15:28:30Z |
Roman Rokytskyy wrote:
DDL in the engine. GDEF and other DDL tools had to perform a sequence
of update operations to instantiate a single logical DDL operation. If
you remove the requirement to support incremental system table update,
you eliminate the requirement for transactional DDL.
Netfrastructure has internal SQL. Not inconsequentially, system tables
are readonly to users, even administrators, even me. Virtually all
metadata operations are performed with "upgrade" DDL that merge new and
old definitions (separate but interesting topic). The only thing that
can't be done incrementally is changing the primary key, not a terrible
restriction. I will say that Netfrastructure was designed from the
ground up to support this ability, so grafting it on Firebird wouldn't
be trivial, but the design philosophies, Borland best efforts not
withstanding, are similar.
I favor deprecating user updatable system tables, which is a 100%
reversal in opinion since you were five. I don't recall your position
was clearly stated at the time I designed Rdb/ELN, but I do allow people
to change their minds based on experience.
database off line without a negative impact on performance, it is a good
thing. And I know we can.
>What was the reason that you were arguing that metadata changes must not beMetadata updates were transactional in Interbase because there was no
>transactional some time ago in FB-Architect?
>
DDL in the engine. GDEF and other DDL tools had to perform a sequence
of update operations to instantiate a single logical DDL operation. If
you remove the requirement to support incremental system table update,
you eliminate the requirement for transactional DDL.
Netfrastructure has internal SQL. Not inconsequentially, system tables
are readonly to users, even administrators, even me. Virtually all
metadata operations are performed with "upgrade" DDL that merge new and
old definitions (separate but interesting topic). The only thing that
can't be done incrementally is changing the primary key, not a terrible
restriction. I will say that Netfrastructure was designed from the
ground up to support this ability, so grafting it on Firebird wouldn't
be trivial, but the design philosophies, Borland best efforts not
withstanding, are similar.
I favor deprecating user updatable system tables, which is a 100%
reversal in opinion since you were five. I don't recall your position
was clearly stated at the time I designed Rdb/ELN, but I do allow people
to change their minds based on experience.
>I think we can agree that if we can design away the need to take a
>
>
>But again, my real world two years ago was batch processing, since that time
>it is a call center of a big insurance company and document workflow
>automation of another insurance company. And there are planned down times.
>
>
database off line without a negative impact on performance, it is a good
thing. And I know we can.