On 20/07/2011, at 12:03 AM, Adrian Crum wrote: > On 7/19/2011 2:07 AM, Scott Gray wrote: >> On 19/07/2011, at 12:51 PM, Adrian Crum wrote: >> >>> Thanks Scott. >>> >>> On 7/19/2011 12:45 AM, Scott Gray wrote: >>>> Hi Adrian, >>>> >>>> Why not replace it with a ProductFeatureContent entity >>>> (PK=productFeatureId:contentId:fromDate), that would follow the pattern >>>> commonly used throughout OFBiz. >>> Then I would have to go through the Content entity to get to the >>> DataResource entity. That seems unnecessarily complicated to me. >> That's how the content data model is designed, virtually nothing in the >> current data model attempts to link directly to the DataResource entity. > > I would hope the design decision to go through the Content entity was based > on something more than "it's always been done that way." If someone wants to > use the image in a CMS, then they can create a Content record that points to > the DataResource.
Of course it was, the Content -> DataResource relationship adds a huge amount of functionality that doesn't exist when referencing a DataResource record directly. To be honest I can't believe we're even having this discussion. Mime types, decoration, pre-rendering service execution, permissions, internationalization and more. I get the impression your view is narrowed to your specific use case (getting a url for an image) and you're not considering the wider implications. >>>> Regarding your example, it would seem more appropriate to link your images >>>> directly to the product, I don't see the justification for needing to link >>>> it to the product feature. Even if you justify it, the best place for >>>> meeting that need would probably be the ProductFeatureAppl entity. >>> Maybe I gave the wrong examples. A better example would be a model X >>> automobile product, with a body color feature, a trim color feature, an >>> upholstery color feature, and driver orientation (left/right) feature. >>> Selecting the various features updates the image of the model X automobile >>> so that it represents the current selections. >> I still don't quite get it, wouldn't placing the images on the variants >> achieve the same thing? I could see potential for what you're talking about >> on configurable products where there is no virtual but I guess you don't >> mean that because we'd be talking about config options instead of product >> features. >> >>>> I'm not a huge fan of overly flexible entity definitions because they can >>>> lead to inconsistent usage across the codebase as different developers >>>> shoehorn it to fit their specific use cases. >>> So fear of inconsistent use should drive design? >> Absolutely, I'd rather not give our committers enough rope with which to >> hang the project. Am I really that concerned about the quality of code >> getting committed? Yes, yes I am. >> >> Besides, you can't just propose a new entity and throw in a bunch of random >> fields with no justification for their presence. As it stands I could use >> your entity to link a partyId and geoId without using a productFeatureId or >> dataResourceId at all, I wonder how long it would take for someone to do >> something like that simply because it's easier than actually doing a proper >> design. > > Would it help the discussion if the new structure looked like this: > > prodFeatDataResId* id-ne > dataResourceId id-ne > productId id > productFeatureId id > fromDate date-time > thruDate date-time > > > ? Not really, we're still missing the justification for inclusion of a productId and I still completely disagree with the direct relation to DataResource. I still think a ProductFeatureContent entity following our standard practices is the best way to go. >> >>>> Regards >>>> Scott >>>> >>>> On 19/07/2011, at 12:22 AM, Adrian Crum wrote: >>>> >>>>> I would like to use the ProductFeatureDataResource entity to connect an >>>>> image to a product feature, but I don't see how that can be done with the >>>>> way the ProductFeatureDataResource entity is constructed. There seem to >>>>> be fields missing, and the way the primary key is set up there is no way >>>>> to connect a data resource to a product + product feature combination. >>>>> >>>>> Example: I have two products - 8 1/2 by 11 paper and a ball point pen. I >>>>> also have a product feature - color: blue. I need to link product 8 1/2 >>>>> by 11 paper + color blue to an image of blue paper, and I need to link >>>>> product ball point pen + color blue to an image of a blue ball point pen. >>>>> The current ProductFeatureDataResource entity does not support that. >>>>> >>>>> It seems to me this entity should be set up more like the PRICE COMPONENT >>>>> entity in the DMRB - where various fields can be filled in to connect a >>>>> data resource to a product, or a product feature, or product + product >>>>> feature, or other combinations of product/order related criteria. >>>>> >>>>> A better version of the ProductFeatureDataResource entity might be: >>>>> >>>>> prodFeatDataResId* id-ne >>>>> dataResourceId id-ne >>>>> productId id >>>>> productFeatureId id >>>>> productCategoryId id >>>>> geoId id >>>>> partyId id >>>>> partyTypeId id >>>>> fromDate date-time >>>>> thruDate date-time >>>>> >>>>> This version would meet the needs of my example, plus it provides the >>>>> flexibility to connect data resources to other combinations of >>>>> product/order related data. >>>>> >>>>> What do you think? >>>>> >>>>> -Adrian >>>>>
smime.p7s
Description: S/MIME cryptographic signature
