Maybe this example will help clarify. You sell a t-shirt, it has variants Red(Rd), Blue (Bl) and Green (Gr) and sizes Small(S), Medium(M) and Large (L)
S Rd T-Shirt - productId = 1000 M Rd T-Shirt - productId = 1001 L Rd T-Shirt - productId = 1002 S Bl T-Shirt - productId = 1003 M Bl T-Shirt - productId = 1004 L Bl T-Shirt - productId = 1005 S Gr T-Shirt - productId = 1006 M Gr T-Shirt - productId = 1007 L Gr T-Shirt - productId = 1008 All GoodIdentification.goodIdentificationTypeId = MARKETING_PROD_ID S Rd T-Shirt - productId = 1000 GoodIdentification.idValue = Shirt-Rd-S M Rd T-Shirt - productId = 1001 GoodIdentification.idValue = Shirt-Rd-M L Rd T-Shirt - productId = 1002 GoodIdentification.idValue = Shirt-Rd-L S Bl T-Shirt - productId = 1003 GoodIdentification.idValue = Shirt-Bl-S M Bl T-Shirt - productId = 1004 GoodIdentification.idValue = Shirt-Bl-M L Bl T-Shirt - productId = 1005 GoodIdentification.idValue = Shirt-Bl-L S Gr T-Shirt - productId = 1006 GoodIdentification.idValue = Shirt-Gr-S M Gr T-Shirt - productId = 1007 GoodIdentification.idValue = Shirt-Gr-M L Gr T-Shirt - productId = 1008 GoodIdentification.idValue = Shirt-Gr-L Foreign keys regarding this product are stored with productId. Products are displayed to users using the idValue. **Note: This is perhaps better modeled by removing productId from GoodIdentification and instead using an associative table between GoodIdentification and Product, but that may be over-designing as the only real downside to the current implementation is duplicate GoodIdentification.idValue. **BTW, this solution solves your field length issue as well as the idValue is arbitrarily set at 60 characters and because it has no meaning to the database, can be expanded to handle more characters if necessary. **Keep in mind storing the autogenerated id as Product.productId with international characters may reduce your potential field length to 5 characters as unicode characters may take up to 4 places per character. --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > Chris, > > I agree with using GoodIdentification value. Recall > our discussion about changing branding and > model numbers we show to customers. > > But then, what would we use for the variants' > productId? The productId field seems to have been > used so extensively now for product ID purposes as > well as for display purposes (ecommerce). > > I hope you're not saying we use a single Product > that has many GoodIdentification values. Then I'd > be really confused. I just got the Variants modeling > (virtual BOMs and all) down pat for my boss! > > Jonathon > > Chris Howe wrote: > > I think this is best handled by reverting r495891 > and > > simply giving instruction for the modification for > > those that wish to use it. With a move towards > > granularity, we should be discouraging this type > of > > use as a primary key to begin with. This auto > > generation should be creating a GoodIdentification > > value instead of a primary key. If the primary > key is > > a surrogate key, let it truly be a surrogate and > > remove the application data meaning surrounding > it. > > Then keep it hidden from the user of the > application. > > > > Once we've finished successfully hiding the > > Product.productId from the user and possibly > scripts > > to regenerate legacy Product Entities, then set up > the > > delimiter as a ProductCatalog setting. > > > > > > --- "David E. Jones" <[EMAIL PROTECTED]> > wrote: > > > >> Here are my previous comments about it earlier on > >> the mailing list: > >> > >> ========================================= > >> This isn't a universal policy or anything, but > I'd > >> say for something > >> minor like this there isn't a problem with > >> hard-coding it. > >> > >> The whole point of the ID generation is to make > the > >> IDs unique. In > >> the UI you can specify an ID instead of using the > >> default, so it only > >> matters so much. > >> ========================================= > >> > >> In general if this sort of thing were to be > >> configurable, would we > >> really want it in a properties file? I'd say no, > >> especially since one > >> of the new objectives that has been discussed > >> recently is to make it > >> easy to configure things, make things > configurable > >> more granularly, > >> and make it easier to use different seed data > files > >> for OOTB industry- > >> specific configurations. > >> > >> What to do... > >> > >> -David > >> > >> > >> On Jan 19, 2007, at 8:59 PM, Scott Gray wrote: > >> > >>> Hi > >>> > >>> I actually said that we should do it if anyone > had > >> objections, but > >>> no one did so that's why it went in as is. But > >> yeah if over- > >>> running the limit is a possibility then it > should > >> probably be > >>> changed. Perhaps there should be some code in > >> there anyway for > >>> coping with that situation, if someones running > >> that many features > >>> saving 1 character might not be much of a bonus. > >>> > >>> Regards > >>> Scott > >>> > >>> Jacopo Cappellato wrote: > >>>> I agree with Si. > >>>> > >>>> Jacopo > >>>> > >>>> Si Chen wrote: > >>>>> Hey there - > >>>>> > >>>>> This patch is a good idea, but I think Scott > >> Gray suggested that > >>>>> this "-" could be configured in a properties > >> file, and I think > >>>>> that's a good idea. Otherwise, if you have > four > >> or five features > >>>>> you will easily overrun the 20-character > >> productId key limit. > >>>>> Keeping it in properties file is a good way to > >> allow it to be > >>>>> modified. Otherwise it's not very nice to > have > >> to go into the > >>>>> code to do it. > >>>>> > >>>>> Jonathon, you up for doing this and sending in > >> another patch? > >>>>> Si > >>>>> > >>>>> > > > -------------------------------------------------------------------- > >>>>> ---- > >>>>> > >>>>> Subject: > >>>>> svn commit: r495891 - > >> /ofbiz/trunk/applications/product/src/org/ > >> ofbiz/product/feature/ProductFeatureServices.java > >>>>> From: > >>>>> [EMAIL PROTECTED] > >>>>> Date: > >>>>> Sat, 13 Jan 2007 12:48:56 -0000 > >>>>> To: > >>>>> [email protected] > >>>>> > >>>>> To: > >>>>> [email protected] > >>>>> > >>>>> > >>>>> Author: jleroux > >>>>> Date: Sat Jan 13 04:48:55 2007 > >>>>> New Revision: 495891 > >>>>> > >>>>> URL: > >> http://svn.apache.org/viewvc?view=rev&rev=495891 > >>>>> Log: > >>>>> A patch from Jonathon Wong "Prepend feature > >> idCodes with > >>>>> '-'" > >> (https://issues.apache.org/jira/browse/OFBIZ-620) > >>>>> Modified: > >>>>> > > > ofbiz/trunk/applications/product/src/org/ofbiz/product/ > >>>>> feature/ProductFeatureServices.java > >>>>> > >>>>> Modified: > > > ofbiz/trunk/applications/product/src/org/ofbiz/product/ > >>>>> feature/ProductFeatureServices.java > >>>>> URL: > > > http://svn.apache.org/viewvc/ofbiz/trunk/applications/ > > > product/src/org/ofbiz/product/feature/ProductFeatureServices.java? > >>>>> view=diff&rev=495891&r1=495890&r2=495891 > >>>>> > > > ==================================================================== > >>>>> ========== > >>>>> --- > > > ofbiz/trunk/applications/product/src/org/ofbiz/product/ > >>>>> feature/ProductFeatureServices.java (original) > >>>>> +++ > > > ofbiz/trunk/applications/product/src/org/ofbiz/product/ > >>>>> feature/ProductFeatureServices.java Sat Jan 13 > >> 04:48:55 2007 > >>>>> @@ -227,7 +227,7 @@ > >>>>> List > newFeatures > >> = new LinkedList(); > >>>>> List > >> newFeatureIds = new > >>>>> LinkedList(); > >>>>> if > >> (currentFeature.getString > === message truncated ===
