[interchange-bugs] [rt.icdevgroup.org #123] [Comment] Administration/Preferences operates on variable database only

[Gert van der Spoel via RT]

http://rt.icdevgroup.org/Ticket/Display.html?id=123
This is a comment.  It is not sent to the Requestor(s):

Comment from Jon ... We have to eventually see how we can combine RT/mailinglist remarks without redundancy. For now I am just copying this, but perhaps is not the right place initially for initiation discussions, without losing the valuable responses which could be found on core/users.


> - Force VariableDatabase to be only 1 instance possible
> 
> Why is it necessary to force VariableDatabase to only allow 1 table?
> You
> can accomplish your other wishes without removing that widely-used
> behavior, can't you? You just have to make it clear that the admin
> variable editing feature will only write to one table if more than one
> is
> specified.

It makes things more transparent in the suggested approach.
It also make it less complex to implement, giving a catalog error when # of VariableDatabase declarations > 1 instead of having to figure out the various VariableDatabase (.txt) files which eventually would have to end up in the same variable table (variable.db, variable.gdbm or the variable table in mysq/pgsql etc) for maintainability ...

 
> > - Add a field to VariableDatabase file 'tier'
> > - standard this tier field would be empty so the variable applies
> >  for all tiers
> > - if you have any Variable that has to be different on another
> >  tier you'd mark the tier accordingly:
> >
> > code    tier   pref_group   Variable
> > SQLDSN         Database     dbi:mysql:DBNAME
> > SQLDSN  UAT    Database     dbi:mysql:DBNAME_ON_UAT
> > SQLDSN  DEV    Database     dbi:mysql:DBNAME_ON_DEV
> >
> > - To accomplish the use of this, a Catalog Directive would be needed,
> for
> > example 'Tier' ... defaults to empty ...
> >
> >  You can set:
> >  Tier UAT, possibly in a tier.cfg file that is called from
> catalog.cfg
> 
> For what it's worth, most End Point Interchange deployments use a
> global
> variable ENVIRONMENT (which is set to production, staging, development,
> etc.) or DEVELOPMENT (a boolean) to determine the environment.

Environment sounds better, but that Directive already exists, that's why "Tier" as it would be fitting the theory pretty much like Environment would.

> And we also put all "tier"-specific configuration in
> interchange_local.cfg
> and catalog_local.cfg, which aren't versioned and are kept as small as
> possible, while interchange.cfg and catalog.cfg live in version control
> and are the same in production and various development environments.

Right, tier.cfg = catalog_local.cfg , that is what I thought as well - only it would probably need less data.

> I wouldn't use the VariableDatabase-with-tier feature if it existed,
> but I
> don't see it causing me any harm either, so I vote 0 on it with warm
> encouragement if the feature will be useful to others.

If it was provided to you in a vanilla install of Interchange you would not go with:
- one existing variable.txt file with the additional Tier field
- one existing catalog_local.cfg with then needed 1 entry: 
  # Provide the identifier for the environment you are running this Interchange install
  # You can differentiate your variables between environments, using this value
  Tier