Hi Shi Yusen,
You mentioned "prodCatalogId". That goes for all other fields of type id-ne, including
Product.productId?
I do agree that improvements need to be made incrementally, so we don't have to wait say a decade
before we can start using the "corrected" OFBiz. As I told Chris, I'd rather not have to
do/witness the painfully arduous task of creating say OFBiz version "ERD Corrected". It works now
for me, and that's all I need (at least until I need to put chinese characters into URLs for
lookups, but I'd use POST usually).
I'm just curious why it was done that way, that's all.
By the way, I was just thinking of importing data, and I realized I wouldn't know the primary keys
when entering data for import if those keys were auto-incremented integer ids. Is that why all
id fields are strings instead of integers?
Maybe I'll dig into the data reader (that imports data from xml files). What happens if my data
for import omits primary key values?
Jonathon
Shi Yusen wrote:
Hi Jonathon,
I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data
Model book. Chris Howe described some issues caused by using the Product.productId under some
circumstances, and they seems closely related to this.
I think ProductId is not discussed in this topic. There's an implicit rule: as
OFBiz is a productivity application, NO EFFICIENCY of OFBiz should be lost when
making any improvements :). Take it easy.
Regards,
Shi Yusen/Beijing Langhua Ltd.
