[ic] 2 stores sharing one product database (Glenn McCalley)

Glenn McCalley glenn at bnetmd.net
Sat May 26 12:59:15 UTC 2012


----- Original Message ----- 
From: "Angus Rogerson" <arogerso at uwaterloo.ca>
To: <interchange-users at icdevgroup.org>
Sent: Friday, May 25, 2012 5:07 PM
Subject: Re: [ic] 2 stores sharing one product database (Glenn McCalley)


>
> We use multiple catalogs running off a single mysql database....
>
> On 2012-05-25, at 8:37 AM, Glenn McCalley wrote:
>
>> Tom, good to know it can work.
>>
>> I don't -think- I want to link order.number in that we want to prefix the 
>> order numbers in the two versions differently so our back end can give us 
>> sales numbers on mobile vs. traditional.
>
> We have separate numbering sequences in each catalog. The prefixes are 
> different so there is no conflict between catalogs.
>
> If you wanted the same numbering sequence across multiple catalogs, you 
> would definitely need to have them linked, but that might not be good 
> enough depending on how your system does file locking.
>
> The COUNTER-1.0 system is defined in Vend::CounterFile and uses 
> Vend::Util::lockfile, which uses Vend:File::lockfile which uses 
> Vend::File::flock_lock which does a system call to flock (See 
> http://perldoc.perl.org/functions/flock.html) to lock the file. Various 
> comments in the code mention the importance of your system using flock for 
> things to work. If your system uses flock you should be fine. If your 
> system is set up to emulate file locking by creating separate lock files 
> you may need to link the whole directory which contains the order.number 
> and other counters. So each catalog has a variable set to tell IC to look 
> for the order.number file in mycounterslink/order.number, where 
> mycounterslink points to allcatalogs/. Then when the file locking system 
> tries to create a lock file it will be in 
> allcatalogs/order.number.lockfile which is shared, instead of 
> mycatalog/order.number.lockfile which is not.
>
>>
>> Also, operational question. do you have to restart both stores when you 
>> update the one database?
>
> "when you update" is a bit vague so I have three answers ...
>
> If you change the data structure then you need to change the 
> dbconf/mysql/...mysql and the products/....txt in both catalogs (or have 
> them linked together). IC keeps the file configurations in each catalog 
> (since normally they would be pointing to different files). So, each 
> catalog would need to be restarted. (This is not a problem for my setup 
> because I am lazy :) and always restart the whole ic server.) Note that 
> this assumes you have already done the mysql alter to change tables in the 
> mysql database.
>
> But note that when I change the data structure I typically need to load 
> new data also. So, I change the dbconf/mysql/whatever.mysql and 
> products/whatever.txt files in *every* catalog, then delete the 
> products/.whatever.sql and products/.whatever.autonumber in *one* catalog. 
> I don't do a mysql alter to change the table structure in mysql. Deleting 
> the .sql and .autonumber files makes Interchange do a mysql drop of the 
> old table and create a new one in mysql, and populate it with data from 
> products/whatever.txt. This only needs to be done by *one* of the 
> catalogs.
>
> Every night I import data into the products and inventory tables in the 
> database using mysqlimport. Mysql deletes all the data and imports the new 
> records. The structure is not changing so IC does not get confused by 
> that. When you do any sort of search/query you are asking the database. 
> So, the catalog does not need to know that the data underneath has 
> changed. Mysql worries about that. No restarts are required.
>
> Hope that helps,
>
> Angus
>
Very much so Angus, thank you.  Good to have confirmation from one who has 
been there.
Glenn.

>
>
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>
> 





More information about the interchange-users mailing list