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?
thanks,
Glen
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.
thanks,
Glen
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.