[ic] database referential issue on new installation
Tue, 9 Jan 2001 15:07:36 -0500
Quoting Jeff (email@example.com):
> I have recently installed Interchange 4.6.1 . I have been able to set up and configure a
> catalog without issue. However, I have encountered two issues. In addition, I have a question.
> The first issue, which is not very important, relates to the
> "design->site layout" section of the administrative GUI. When an
> "area" is added, deleted, or moved using this interface, the "sort"
> columns are not properly updated. It is very easy to end up with two
> areas with the same sort value which causes discrepancies between the
> admin GUI's listbox and the end-user's section listing.
> The second issue, which is more important to me, is something that
> occurred when I deleted items out of the "construct" sample catalog.
> Using "items->item list" in the administrative GUI, I checked multiple
> items to be deleted and pressed the "Delete checked items" button. The
> issue that I am having is that this didn't appear to delete the items
> properly. It did indeed delete the items from the products table but
> not from the merchandising, inventory, pricing, and other tables. The
> items still show up on the end-user web site, just with no description.
> I am assuming I will have to now look through each table and delete
> rows associated with the deleted products. I am wondering if this is
The deletion is only from products in 4.6.x. The rest have to be deleted
manually. This will be changed for 4.7.x.
But your problem is not the deletion, it is that the items remain in
the products.txt file. Remember that you are not searching the merchandising
table or pricing table. Try doing an export so the products.txt file matches
what is in the database.
> I am currently using GDBM and seem to be running into concurrency
> issues, users on the web site encounter GDBM errors if I happen to be
> updating certain tables at the same time. I am wondering if
> interchange "prefers" mysql as opposed to GDBM.
This is normal. Unfortunately locking is not that great for GDBM, on a
table basis only, and if an update takes too long the retries will run
out of time and an error will occur. There should be no corruption of
data, just locking/contention issues that go away when you stop updating.
We recommend that you use a SQL database for the frequently-written tables
userdb, orderline, and transactions if possible. Other read-mostly databases
are less important in that regard.
That being said, there are sites doing a million parsed pages a month which
use GDBM. It works, just not well in a multi-user environment. SQL is better
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH 45056
phone +1.513.523.7621 fax 7501 <firstname.lastname@example.org>
For a successful technology, reality must take precedence over public
relations, for Nature cannot be fooled. -- Dick Feynman