BIGINT big headache

I’m importing thousands of products (using Mapforce) and I need a way to create “predictable” IDs. Essentially, I’m prepending the supplier’s product ID (7 digits) with 3 additional digits which identify the supplier, option type, etc. The result is a very long ID that tells me a lot of information at a glance.

A product ID might look like 5001234567. An image_id for this would look like 5101234567. An option_id would look like 5301234567. and so on.

Unfortunately, this ID scheme exceeds the limits of CS-Cart’s MEDINT field type. To remedy this, I’ve converted all related field types to BIGINT (because INT is also too small).

I’ve imported my product data, and CS-Cart displays the products without a problem. Unfortunately, the cart seems to have some issues with BIGINT when I use the admin to create a new product, product option, variant, etc. Something in the site code is throwing a “stack overflow” (ex. inserting 705032704 in place of 5000000000).

Does anyone know where/how CS-Cart handles IDs? I’ve looked at core/fn.database.php and see a function called db_intval - but that code is over my head.

Alternatively, can anyone recommend a different strategy to create “predictable” IDs? Perhaps I should create a BIGID → ID lookup table - but how do I keep that current as changes are made via CS-Cart’s admin?



You are using product_id the way it is NOT intended.

Don’t mess with the product_id. It’s just a unique identifier for database JOINs.

Why don’t you the product_code or create a new product feature such as ‘sku’ or ‘model number’ or whatever you like.

[quote]Why don’t you the product_code or create a new product feature such as ‘sku’ or ‘model number’ or whatever you like.[/quote]

In this scenario, how would I programmatically find the variant_id for the color “Red” in the product option “Color” for the product with a product feature “SKU” that equals 123456 so that I could change it to “Green”? Any UPDATE statement would require a lot of (slow) subqueries to follow the ID trail that far.

Obviously, I could easily edit the item’s variant color via CS-Cart’s admin - but that isn’t practical when I might have 10,000 products that need to be updated.



Unfortunately what makes a 3rd Normal Form database extremely fast and efficient at storing and retrieving data, also makes programming a little more complicated. Yes you must incorporate looking up the primary key into your code or join to the table containing the primary key to get what you want.

Product_Code would be the appropriate place to store your long UPC or SKU’s etc.