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.
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
?
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
