[ic] Multiple catalog control and/or editing

Paul Jordan paul at gishnetwork.com
Sat Oct 8 15:47:50 UTC 2011


I am wondering if anyone has any tips, tricks, or clever setups that assist 
with editing/maintaining multiple systems. Imagine you have systems for 
clients and anywhere from 10% - 60% of each system could be identical on 
almost all clients. For example, order processing might be the same for 

Is there a way to setup a server, using vendroot/pages/admin style 
overrides, symlinks, etc, so that:

#1 the base system is installed on multiple catalogs (no matter if they 
served by the same IC deamon or not).

#2 in a way I can add pages to any number of installs instantly.

#3 in a way I can edit pages on any number of installs instantly.

#4 in a way that I can override, or add pages to one or more installs.

Basically, I want to more efficiently manage multiple semi-similar Admins, 
and use the same code (pages) wherever possible. I want to avoid needing to 
"roll out" changes to standard components for each client individually.

Also, regarding base/shared data. Obviously I can create a schema and then 
JOIN a table in that schema with multiple tables in multiple other schemas 
to facilitate "base" or default data for multiple systems. Is this the only 
way and is there anything more clever or robust? I want to avoid having 
redundant default data in separate client installs, and if that data needs 
to be updated or added to, I don't want to edit each one individually. I 
used to use Views to do some similar type of tricks, but I've learned that 
Views can't be indexed, at least in Mysql. Someone mentioned to me 
copy-on-write updating as well. I'd like to know if anybody is using setups 
in ways described above and if they are happy or what problems they run 

I use Mysql but would consider changing to Postgres.

Yes, I realize it makes the catalogs less portable. But, I'd rather take 
more time when moving systems, which is rare, than taking more time for all 
edits, which can be daily or at least weekly.


More information about the interchange-users mailing list