David, Whether OOTB Ofbiz will support both ways or not doesn't make exposing the primary key to the user any less dangerous.
The generated Id in the variant example should be the marketing product id in GoodIdentification, not the primary key Product.productId. The marketing product id you show to the user, the primary key Product.productId, you hide. As the user of the data, the customer is concerned with the marketing product id, not the primary key productId. The primary key product Id is [should be] a surrogate key ( http://en.wikipedia.org/wiki/Surrogate_key ). It has no meaning except to uniquely identify a product in the database, not in real life. As your foreign key in your OrderHeader entity, you would have your Product.productId. What shows up on the UI for the sales order is the marketing product Id. When displaying a phone number, do you show the user the contactMechId? --- "David E. Jones" <[EMAIL PROTECTED]> wrote: > > Chris, > > The point is that in the system we're going to > support both ways. > That's it. I see no good reason to write a bunch of > stuff to force > one way or another, especially when we've already > written stuff > (that's fairly simple really) to allow both. > > Another thing to consider: even if a productId is > generated it > doesn't mean you necessarily want it hidden. People > may want to write > it down, have fields where they can enter with a > barcode scanner, > etc, much like an order or invoice ID. > > -David > > > On Jan 20, 2007, at 12:15 AM, Chris Howe wrote: > > > I agree that the delimiter issue is very, very > small, > > however the manner in which the order and > ecommerce > > component utilize the productId is not unique in a > > company's life cycle. Granted, you won't run into > > this problem on initial deployment or if your > product > > never changes. But very few companies keep their > > product the exact same over the span of several > years. > > > > To give you a real life example of the problem > this > > practice exposes. > > We do business with a company that exposes their > > primary key as their productId that we order with. > > They manufacture power wheelchairs. Their vendor > for > > the seat kit (upholstery and mounting hardware) on > the > > chairs started becoming unreliable with delivery > and > > they had to get the upholstery from another vendor > > (began as a mixed utilization before going > completely > > with the new vendor). In order to keep up their > > quality control tracking, they had to issue a new > > productId to distinguish the two chairs apart as > seat > > kits are not serialized. They allow their > customers > > to view real time inventory. They weren't able to > > effectively communicate this change of productId > to > > their customers, so their customers kept getting > "out > > of stock" messages on the power wheelchairs. > Their > > customers ended up meeting their chair needs from > > other suppliers. They experienced a 25% decline > in > > power wheelchair sales in the quarter this > occurred, > > had to discount their overstock the following > quarter > > and they have yet to win back many of the > customers > > that fulfilled their initial orders with another > > supplier as well as the customers who now have the > > perception of a "new" untested chair on the > market. > > > > Because of a change in upholstery they had to > consider > > the ramifications on marketing, sales force > training, > > and inventory. This really isn't necessary. To > the > > customers these are the exact same chairs, they > should > > be ordering them with the exact same marketed > > productId. Their inventory counts should be > > consolidating the separate counts. Their sales > force > > should not be worried about how to explain the > > differences in the two chairs. This could be a > lot > > simpler. > > > > This may be an extreme change, but it's extremely > more > > flexible and more accurately describes a > business's > > product line. > > > > ,Chris > > > > --- "David E. Jones" <[EMAIL PROTECTED]> > wrote: > > > >> > >> I think this is a little extreme, and I'm not > sure > >> hiding the > >> productId is a good idea. The way it is now works > >> really well for > >> most companies I've worked with. And for the > rest, > >> having the > >> productIds visible is not too much a problem, and > >> they can be > >> sequenced just fine. > >> > >> I should maybe say it again: this change it SO SO > SO > >> MINOR it is > >> hardly worth reading the commit, let along > >> discussing it. It is a > >> default setting for a fairly special purpose UI > and > >> the ID can be > >> manually set in the UI anyway. > >> > >> -David > >> > >> > >> On Jan 19, 2007, at 10:31 PM, 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... > === message truncated ===
