Re: [mv] master/slave catalogs - (products & checkout)

[cfm@maine.com]

******    message to minivend-users from cfm@maine.com     ******

On Sun, Jul 30, 2000 at 08:16:44AM -0400, Mike Heins wrote:
> ******    message to minivend-users from Mike Heins <mikeh@minivend.com>     ******
> 
> Quoting Dave Barr (barrd@cricinfo.com):
> > 
> > Hi MiniVenders,
> > 
> > [Debian 2.2 / MiniVend 4.04]
> > 
> > I'm hoping that someone might be able to help/advise me as to the 
> > best course of action regarding LARGE numbers of catalogs (in time 
> > several thousand, ulp ;).
> 
> Hmm. This would argue for a completely table-based virtual catalog
> setup. This is very doable with Interchange, and we will be coming out
> with a template eventually. Consider:
...
> 
> You just set up an Autoload that looks for the catalog ID

We use a rig like this below, only we load it into session.  In
that sense, yes, there is a "master" catalog, but it is one
designed to contain the dynamic catalogs.

   $query=q`SELECT M.account,M.* FROM site_config.merchants AS M WHERE FIND_IN_SET(account,'`.
        (join ',', @cats).
            q`')`;
    @A=&Vend::CFM::db_array_query($query);
    foreach (@A) {
        my($cat);
        $cat = $_->[0];
        for($i = 0; $i <= @{$f{FIELDS}}; $i++) {
            $Vend::Session->{values}{merchants}{$cat}{$f{FIELDS}[$i-1]} = $_->[$i];
        }
    }


Most of this table is pretty obvious.  The interesting parts are
attributes, basket_display, cc_types, extras and things like
that.  Those allow on the fly, run-time configuration of the basket and
checkout sequence, they allow one to specify what shows in
basket, what shows in report, etc....  As far as we are concerned,
this is all about how our non-technical front office can set up
entry level storefronts online.  And to answer the big question,
no, it does not all work yet.  It did work in pre-pre-pre-beta before
we started converting to mv4.

Anyway, that is the master plan.  Progress is slow.  ;^)

#
# Table structure for table 'merchants'
#
CREATE TABLE merchants (
  account varchar(32) DEFAULT '' NOT NULL,
  address_block text,
  annum date,
  attributes tinytext,
  basket_display tinytext,
  box tinytext,
  cc_types tinytext,
  config varchar(64),
  contact tinytext,
  dailies int(11) DEFAULT '0' NOT NULL,
  email tinytext NOT NULL,
  extras tinytext,
  fine_print text,
  fx_phone varchar(32),
  http_top tinytext,
  id int(11),
  lm timestamp(14),
  order_instructions text,
  order_validate text,
  org_name tinytext,
  payment_types varchar(64),
  reply_email varchar(128),
  report_attributes tinytext,
  report_email varchar(128),
  shipping_email text,
  shipping_table text,
  shipping_types varchar(128),
  state varchar(32),
  status int(11),
  street tinytext,
  tbls_active tinytext,
  town varchar(32),
  validate text,
  vlink tinytext,
  wk_phone varchar(32),
  zip varchar(32),
  zrow int(11) DEFAULT '0' NOT NULL auto_increment,
  UNIQUE account (account),
  KEY zrow (zrow)
);




> 
> > 
> > After reading through the dox and hours spent reading through the 
> > archives I haven't come across any real answers regarding running a 
> > master catalog and hanging slaves from it. I like the idea as I will 
> > be sharing the HTML pages driven as templates and most of the 
> > database files (esp shipping, & userdb).
> > However the only real differences between the shops will be the 
> > products that they carry (easily changed by altering the ProductFiles 
> > directive, or so I thought ;)
> > 
> > Having created 3 shops as a test the basket page will pick up the sku 
> > of any orders placed in any other shop in the chain - but as each 
> > shop has its own unique products file it 'obviously' doesn't have the 
> > supporting price, description etc. (This (the sku) I presume is 
> > gleaned from the session db for the master catalog?). I actually want 
> > each shop to be an autonomous unit, so that from entry page through 
> > checkout to receipt follows its own template variables and only 
> > reflects its own unique products (and maybe those of the master cart, 
> > again easily sorted with the ProductFiles directive). Has anyone 
> > worked out a workaround for removing unwanted products from other 
> > carts using the master/slave model for this? Or is it indeed possible?
> > 
> > Talking of which, can anyone explain why using this model that no 
> > matter which shop you are going through when clicking for "Check Out" 
> > it will always default to the master catalog (inheriting its template 
> > variables et al), yet the basket page (as specified under "Special" 
> > pages in the master catalog file) is called in exactly the same way 
> > i.e.
> > 
> > [snip catalog.cfg]
> > SpecialPage          checkout       __ORDER_STYLE__/checkout
> > SpecialPage          order          __ORDER_STYLE__/basket
> > [/snip]
> > 
> > I assume this is "hard coded" somewhere deep within the MiniVend lib routines?
> > 
> 
> No, it is just that the subcatalog is configured with no knowledge of the
> master's settings. It cannot read a variable set there.
> 
> -- 
> Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
> phone +1.513.523.8220 fax 7501 <heins@akopia.com>
> 
> I have a cop friend who thinks he ought be able to give a new ticket;
> "too dumb for conditions".
> -
> To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
> email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
> Archive of past messages: http://www.minivend.com/minivend/minivend-list

-- 

Christopher F. Miller, Publisher                             cfm@maine.com
MaineStreet Communications, Inc         208 Portland Road, Gray, ME  04039
1.207.657.5078                                       http://www.maine.com/
Database publishing, e-commerce, office/internet integration, Debian linux.
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list