[ic] centralized variable table - can it be done?

Bruno Cantieni bruno at digi-land.com
Wed Nov 16 09:00:14 EST 2005


 

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org 
> [mailto:interchange-users-bounces at icdevgroup.org] On Behalf 
> Of Bruno Cantieni
> Sent: November 14, 2005 4:49 PM
> To: interchange-users at icdevgroup.org
> Subject: RE: [ic] centralized variable table - can it be done?
> 
>  
> 
> > -----Original Message-----
> > From: interchange-users-bounces at icdevgroup.org 
> > [mailto:interchange-users-bounces at icdevgroup.org] On Behalf 
> > Of Stefan Hornburg
> > Sent: November 14, 2005 8:38 AM
> > To: interchange-users at icdevgroup.org
> > Subject: Re: [ic] centralized variable table - can it be done?
> > 
> > Bruno Cantieni wrote:
> > > Hello all.
> > > 
> > > Our client runs a merchant network of 40+ merchants/catalogs.
> > > All the merchants catalogs are administered centrally 
> > (individual merchants
> > > have no admin functions other than basic order management) 
> > and many tables
> > > are global using a merchant_id field to identify 
> individual merchant
> > > records.
> > > For ease of administration we would now also like the 
> > catalogs to read their
> > > rsp. variables from a "global" mysql variable table (keyed by
> > > catalog/merchant id) rather than from individual variable 
> > tables (currently
> > > using variable.gdbm) on restarts/reconfigs.
> > > While globalizing tables such as "products" was a 
> > no-brainer, I'm at a bit
> > > of a loss as to how we might implement this with "variable" 
> > or of it is even
> > > possible.
> > > Any thoughts on this would be appreciated.
> > 
> > You can add rows from an arbritrary database to the variabls:
> > 
> > # variable database
> > ParseVariables Yes
> > Database central central.txt __SQLDSN__
> > Database central USER __SQLUSER__
> > Database central PASS __SQLPASS__
> > ParseVariables No
> > 
> > NoImport central
> > 
> > VariableDatabase central
> > 
> > If you need changes immediately visible, you can put the values from
> > "central" into the variables namespace with an Autoload routine.
> > 
> > Example:
> > 
> > Sub <<EOS
> > sub load_settings {
> > 	$Tag->perl({tables => 'settings_names'});
> > 
> > 	my %other_keys = (base_url => 1,
> > 					  default_mo => 1,
> > 					  default_rabatt_1_shop => 1,
> > 					  min_amount_artikeldaten => 1,
> > 					  std_email_subj => 1,
> > 					  dollar => 1);
> > 
> > 	my $set = $Db{settings_names}->query({sql => 'select * 
> > from settings_names', hashref => 1});
> > 	for (@$set) {
> > 		if ($_->{settings} =~ /^organization/ || 
> > $other_keys{$_->{settings}}) {
> > 			$::Variable->{uc($_->{settings})} = $_->{value};
> > 		}
> > 	}
> > }	
> > EOS
> > 
> > Please consider the affect on the performance.
> > 
> > Bye
> > 	Racke
> > 
> 
> Thank you Racke.
> The approach confirms the one idea I had come up with and 
> your sample code
> will save me oodles of time racking my brain (couldn't help 
> that one :)
> Tschüss
> Bruno Cantieni
> 

I have now played around with this idea for a bit with limited success.
I was really hoping to be able to pick up all variables normally supplied by
"VariableDatabase variable" this way, however it appears I can not eliminate
"VariableDatabase" altogether.
My current code (just the meaty bits) is as follows:

Variable    MERCHANT_ID        1001
ParseVariables Yes
NoImport merchant
### Spool up the variables
Sub <<EOS
sub load_settings {
	$Tag->perl({tables => 'merchant'});
	my $db = $Db{merchant};
	my @columns = $db->columns();
	my $rec = $db->row_hash(__MERCHANT_ID__);
	for (@columns) {
		$::Variable->{uc($_)} = $rec->{$_};
	}
}	
EOS

ParseVariables No

## Autoload above defined routine
Autoload load_settings

VariableDatabase variable

If I eliminate (comment out) the "VariableDatabase variable" line (or delete
certain variables from the variable db),
I won't get a whole bunch of variables picked up by reconfig even though
they have been placed in $::Variable by the above sub.
e.g. "ORDERS_TO", "CGI_URL" and others.
Many others work just fine this way.

??

Regards,
Bruno Cantieni





More information about the interchange-users mailing list