Re: [Firebird-devel] RFC: Major changes in ODS 12

[Pavel C. <pc...@ib...>]

Leyne, Sean napsal(a):
> 
>> Mark Rotteveel> I'd say: choose one method of storing per database 
>> settings and stick with it.
>> 
>> In view of that per-database conf file will be used in any case 
>> (for other goals), i'd prefer configuring curent db-header options 
>> there (in files). But why already existed options must be cleaned 
>> from db-header is not so obvious for me.
>> 
>> New options must be stored and configured via files, of course.
> 
> This is a middle option which is a disaster...
> 
> "So, if I move my database to another server/folder, I will need to
> move the separate conf file as well!"
> 
> Nuts to that!!!
> 
> Store all of the *specified* database settings (remembering not all
> settings are *database* settings) in the database header.
> 
> If a specific setting/parameter doesn't exist in the header, then the
> default value in the server/folder config file will apply.
> 
> In this way the database owner can define his configuration, while
> the server/host manager can define his settings.

Yeah, let's the flamewar begin :-) Seriously, both approaches how to
store the database configuration options have their pros & cons. Let's
summarize them a bit...

1) Configuration right in database

Pros:
- It goes where the database goes when it's moved: backup (both gbak and
nbackup) or new location or even shadow. However it's not propagated
when other replication techniques are used. Actually, this is a mixed
blessing as it could be also a drawback, because one has to re-check the
configuration after restore from backup or move (I saw
blast-from-the-past misconfigurations too many times, especially 0 sweep
interval stored in backup could be a disaster when one doesn't expect it
to reappear after restore).
- You don't need direct access to files on the server.

Cons:
- You need a special tool to see and change the configuration.
- Risk of Blast-from-the-past misconfiguration mentioned above.

2) Configuration in database-specific (text) configuration file

Pros:
- You don't need any special tool to see and change the configuration.
- The configuration file could be self-documented.

Cons:
- You need direct access to configuration file on the server.
- The configuration is not part of the backup (although I'd consider it
a plus, not drawback)
- You have to copy the configuration file along with database if you
*want* to retain it's configuration in new location.
- A danger of misconfiguration due to use of wrong file if there is not
clear (and simple) definition where this configuration file is located.

Personally, I would vote for 2) any sober day. However, I'd see two
things in it's initial implementation:

a) clear and simple rules for config file placement, for example file
must have the same name as the database (with .conf extension) and
located either in database directory or directory defined as "global
config directory" in firebird.conf.

b) ability to read/write config file via Services API.

best regards
Pavel Cisar
IBPhoenix