Discussion: ProductFeatureDataResource Entity
Locked
Discussion: ProductFeatureDataResource Entity
 
|
Re: Discussion: ProductFeatureDataResource Entity
|
|
Hi Adrian,
Why not replace it with a ProductFeatureContent entity (PK=productFeatureId:contentId:fromDate), that would follow the pattern commonly used throughout OFBiz. 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. 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. 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 (3K)
Re: Discussion: ProductFeatureDataResource Entity
|
|
Re: Discussion: ProductFeatureDataResource Entity
|
|
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. >> 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. >> >> 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 >>> |
Re: Discussion: ProductFeatureDataResource Entity
|
|
Re: Discussion: ProductFeatureDataResource Entity
|
|
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. >>>> 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 >>>>> |
Re: Discussion: ProductFeatureDataResource Entity
|
|
Re: Discussion: ProductFeatureDataResource Entity
|
|
On 20/07/2011, at 12:31 AM, Adrian Crum wrote:
> On 7/19/2011 1:19 PM, Scott Gray wrote: >> 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. > > A product feature might apply to more than one product, so both bits of information are needed to select the correct image. ProductFeatureContent productFeatureId* contentId* productFeatureContentTypeId* (or perhaps an enum instead of yet another type entity) fromDate* thruDate productId The definition above follows the same pattern used by ProductContent, ProductCategoryContent, ProductPromoContent (name?) and plenty of other entities that link into the content model. I worked on a project recently where we did something similar with ProductContent except the additional field was for a productStoreId which allowed us to use specific product names, descriptions, images, etc. for different product stores and also provide a general default by leaving the field null. >> >>>>>> 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 >>>>>>> |
Re: Discussion: ProductFeatureDataResource Entity
|
|
Re: Discussion: ProductFeatureDataResource Entity
|
|
On 20/07/2011, at 2:48 AM, Adrian Crum wrote:
> On 7/19/2011 2:40 PM, Scott Gray wrote: >> On 20/07/2011, at 12:31 AM, Adrian Crum wrote: >> >>> On 7/19/2011 1:19 PM, Scott Gray wrote: >>>> 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. >>> A product feature might apply to more than one product, so both bits of information are needed to select the correct image. >> I'm still not entirely sure of the use case, but I could live with something like: >> ProductFeatureContent >> productFeatureId* >> contentId* >> productFeatureContentTypeId* (or perhaps an enum instead of yet another type entity) >> fromDate* >> thruDate >> productId >> >> The definition above follows the same pattern used by ProductContent, ProductCategoryContent, ProductPromoContent (name?) and plenty of other entities that link into the content model. >> >> I worked on a project recently where we did something similar with ProductContent except the additional field was for a productStoreId which allowed us to use specific product names, descriptions, images, etc. for different product stores and also provide a general default by leaving the field null. > > Actually, adding the productFeatureId field to the ProductContent entity would satisfy the need. I can extend the entity for this project. Thanks for the help! >>>>>>>> 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 >>>>>>>>> |
Re: Discussion: ProductFeatureDataResource Entity
Administrator
|
From: "Scott Gray" <[hidden email]>
>>>>>>>> No worries, glad you've found a solution that will work for you. By the way, thank you for starting discussions like this, >>>>>>>> it's so rare these days that a committer will actually discuss significant changes/features with the community before >>>>>>>> diving into the >>>>>>>> implementation. The value of these types of threads really can't be overstated. Yes, that's so true ! Thanks to both for sharing your thoughts Jacques >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> On 19/07/2011, at 12:22 AM, Adrian Crum wrote: |
| Free forum by Nabble | Edit this page |