You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2012/10/01 08:14:54 UTC
Proposal: Entity Subtype Implementation
I mentioned this once before as part of another discussion, but I'm
creating a new discussion so it can receive the attention it deserves.
The Data Model Resource Book describes entity subtypes. OFBiz implements
entity subtypes by adding a field to the supertype that points to a
*Type entity that contains valid subtypes.
The problem is users (and some developers) do not understand that
pattern, and they add invalid subtypes to the *Type entity. That can
cause things to break. As an example, I have a client who created
additional ProductTypes (that actually represented product categories)
and used those added ProductTypes for their products. Then they were
puzzled why their order fulfillment process stopped working.
I think what we need is an EntitySubtype entity to store the subtype
data. Instead of multiple *Type entities, we would have a single
EntitySubtype entity, and the supertypes will point to it. The supertype
field could be called something like entitySubtypeId. The EntitySubtype
entity will be clearly documented as to its purpose and proper use.
EntitySubtype
-------------
entityName*
entitySubtypeId*
description
What do you think?
-Adrian
Re: Proposal: Entity Subtype Implementation
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 10/2/2012 1:13 AM, Scott Gray wrote:
> On 1/10/2012, at 7:14 PM, Adrian Crum wrote:
>
>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>>
>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>>
>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>>
> To be honest I don't think this is a good reason to change anything. A basic and fundamental misunderstanding of the data model isn't a reason to drive change in anything except perhaps better documentation.
>
> *Type entities also provide some flexibility by allowing additional fields to be used to describe common behavior of various types such as ProductType's isDigital and isPhysical, personally this is a feature of the design that I'd like to see put into greater use. An example of that might be having a defaultDataResourceTypeId or defaultMimeTypeId on ProductContentType so that the most appropriate form for the given ProductContentType can be displayed, currently that sort of thing is hardcoded into a groovy script if I recall correctly.
There are better ways to handle those datums. isDigital and isPhysical
are product features. ProductContentType does not describe an entity
subtype - so that entity will not change.
I could create a list of which entities implement subtypes - maybe that
will help clear up any confusion.
>
> Perhaps in the future strong use of those fields could lay a better foundation for allowing user's to create their own types simply by indicating the desired behaviors.
>
> Regards
> Scott
>
Re: Proposal: Entity Subtype Implementation
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 1/10/2012, at 7:14 PM, Adrian Crum wrote:
> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>
> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>
> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>
To be honest I don't think this is a good reason to change anything. A basic and fundamental misunderstanding of the data model isn't a reason to drive change in anything except perhaps better documentation.
*Type entities also provide some flexibility by allowing additional fields to be used to describe common behavior of various types such as ProductType's isDigital and isPhysical, personally this is a feature of the design that I'd like to see put into greater use. An example of that might be having a defaultDataResourceTypeId or defaultMimeTypeId on ProductContentType so that the most appropriate form for the given ProductContentType can be displayed, currently that sort of thing is hardcoded into a groovy script if I recall correctly.
Perhaps in the future strong use of those fields could lay a better foundation for allowing user's to create their own types simply by indicating the desired behaviors.
Regards
Scott
Re: Proposal: Entity Subtype Implementation
Posted by Olivier Heintz <ho...@nereide.biz>.
For the user (or developers) who not understand that pattern, I think it
will not more clear.
But, on a Data Model perspective I prefer only one entity than multiple.
With one entity, it will be possible to have only one entity for
EntitySubTypeAttr and EntityAttr and so having a generic User interface
(user configurable portlet) which will be usable.
In the EntitySubtype, I will add the field hasTable, to generalize the
same concept as Party with Person and PartyGroup, only the fields uses
by all type in Party and specifics Field in dedicated entity.
Example : It will be necessary to have same things for WorkEffort
So, +1 for your idea as a first step ;-)
Olivier
Le 01/10/2012 08:14, Adrian Crum a écrit :
> I mentioned this once before as part of another discussion, but I'm
> creating a new discussion so it can receive the attention it deserves.
>
> The Data Model Resource Book describes entity subtypes. OFBiz
> implements entity subtypes by adding a field to the supertype that
> points to a *Type entity that contains valid subtypes.
>
> The problem is users (and some developers) do not understand that
> pattern, and they add invalid subtypes to the *Type entity. That can
> cause things to break. As an example, I have a client who created
> additional ProductTypes (that actually represented product categories)
> and used those added ProductTypes for their products. Then they were
> puzzled why their order fulfillment process stopped working.
>
> I think what we need is an EntitySubtype entity to store the subtype
> data. Instead of multiple *Type entities, we would have a single
> EntitySubtype entity, and the supertypes will point to it. The
> supertype field could be called something like entitySubtypeId. The
> EntitySubtype entity will be clearly documented as to its purpose and
> proper use.
>
> EntitySubtype
> -------------
> entityName*
> entitySubtypeId*
> description
>
> What do you think?
>
> -Adrian
>
>
Re: Proposal: Entity Subtype Implementation
Posted by Adrian Crum <ad...@sandglass-software.com>.
The user will not see the EntitySubtype entity because it will not be a
part of the UI. In other words, a user can't add new subtypes. There can
be a UI in Web Tools for adding entity subtypes, but like I said, it
will clearly describe the pattern and the correct usage.
-Adrian
On 10/1/2012 10:14 AM, Olivier Heintz wrote:
> For the user (or developers) who not understand that pattern, I think
> it will not more clear.
> But, on a Data Model perspective I prefer only one entity than multiple.
> With one entity, it will be possible to have only one entity for
> EntitySubTypeAttr and EntityAttr and so having a generic User
> interface (user configurable portlet) which will be usable.
>
> In the EntitySubtype, I will add the field hasTable, to generalize the
> same concept as Party with Person and PartyGroup, only the fields uses
> by all type in Party and specifics Field in dedicated entity.
> Example : It will be necessary to have same things for WorkEffort
>
> So, +1 for your idea as a first step ;-)
>
> Olivier
>
> Le 01/10/2012 08:14, Adrian Crum a écrit :
>> I mentioned this once before as part of another discussion, but I'm
>> creating a new discussion so it can receive the attention it deserves.
>>
>> The Data Model Resource Book describes entity subtypes. OFBiz
>> implements entity subtypes by adding a field to the supertype that
>> points to a *Type entity that contains valid subtypes.
>>
>> The problem is users (and some developers) do not understand that
>> pattern, and they add invalid subtypes to the *Type entity. That can
>> cause things to break. As an example, I have a client who created
>> additional ProductTypes (that actually represented product
>> categories) and used those added ProductTypes for their products.
>> Then they were puzzled why their order fulfillment process stopped
>> working.
>>
>> I think what we need is an EntitySubtype entity to store the subtype
>> data. Instead of multiple *Type entities, we would have a single
>> EntitySubtype entity, and the supertypes will point to it. The
>> supertype field could be called something like entitySubtypeId. The
>> EntitySubtype entity will be clearly documented as to its purpose and
>> proper use.
>>
>> EntitySubtype
>> -------------
>> entityName*
>> entitySubtypeId*
>> description
>>
>> What do you think?
>>
>> -Adrian
>>
>>
>
Re: Proposal: Entity Subtype Implementation
Posted by Olivier Heintz <ho...@nereide.biz>.
For the user (or developers) who not understand that pattern, I think it
will not more clear.
But, on a Data Model perspective I prefer only one entity than multiple.
With one entity, it will be possible to have only one entity for
EntitySubTypeAttr and EntityAttr and so having a generic User interface
(user configurable portlet) which will be usable.
In the EntitySubtype, I will add the field hasTable, to generalize the
same concept as Party with Person and PartyGroup, only the fields uses
by all type in Party and specifics Field in dedicated entity.
Example : It will be necessary to have same things for WorkEffort
So, +1 for your idea as a first step ;-)
Olivier
Le 01/10/2012 08:14, Adrian Crum a écrit :
> I mentioned this once before as part of another discussion, but I'm
> creating a new discussion so it can receive the attention it deserves.
>
> The Data Model Resource Book describes entity subtypes. OFBiz
> implements entity subtypes by adding a field to the supertype that
> points to a *Type entity that contains valid subtypes.
>
> The problem is users (and some developers) do not understand that
> pattern, and they add invalid subtypes to the *Type entity. That can
> cause things to break. As an example, I have a client who created
> additional ProductTypes (that actually represented product categories)
> and used those added ProductTypes for their products. Then they were
> puzzled why their order fulfillment process stopped working.
>
> I think what we need is an EntitySubtype entity to store the subtype
> data. Instead of multiple *Type entities, we would have a single
> EntitySubtype entity, and the supertypes will point to it. The
> supertype field could be called something like entitySubtypeId. The
> EntitySubtype entity will be clearly documented as to its purpose and
> proper use.
>
> EntitySubtype
> -------------
> entityName*
> entitySubtypeId*
> description
>
> What do you think?
>
> -Adrian
>
>
Re: Proposal: Entity Subtype Implementation
Posted by Adrian Crum <ad...@sandglass-software.com>.
You're not understanding the design. The EntitySubtype entity implements
entity subtypes only, it does not replace all *Type entities. There are
*Type entities in the DMRB that are not related to entity subtypes - so
those will remain unchanged.
The ProductType entity implements Product subtypes, so it would be
replaced with the EntitySubtype entity.
-Adrian
On 10/8/2012 6:23 AM, Jacopo Cappellato wrote:
> Well, no I didn't.
>
> If I understand your design, you are proposing to keep the ProductType entity and add a generic EntitySubtype entity for *subtypes*; the pattern described in the EntitySubtype is similar to the one proposed by David for the *Type entities.
> Keeping the existing pattern for Type entities and adding the new one for the subtypes in my opinion is ugly and confusing, this is the main reason I don't like it.
>
> Jacopo
>
>
>
>
> On Oct 6, 2012, at 7:19 PM, Adrian Crum wrote:
>
>> So your opinion has changed...
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@hotwaxmedia.com%3E
>>
>> -Adrian
>>
>>
>> On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
>>> HelloAdrian,
>>>
>>> in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>> On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
>>>
>>>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>>>>
>>>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>>>>
>>>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>>>>
>>>> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>>>>
>>>> EntitySubtype
>>>> -------------
>>>> entityName*
>>>> entitySubtypeId*
>>>> description
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
Re: Proposal: Entity Subtype Implementation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Well, no I didn't.
If I understand your design, you are proposing to keep the ProductType entity and add a generic EntitySubtype entity for *subtypes*; the pattern described in the EntitySubtype is similar to the one proposed by David for the *Type entities.
Keeping the existing pattern for Type entities and adding the new one for the subtypes in my opinion is ugly and confusing, this is the main reason I don't like it.
Jacopo
On Oct 6, 2012, at 7:19 PM, Adrian Crum wrote:
> So your opinion has changed...
>
> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@hotwaxmedia.com%3E
>
> -Adrian
>
>
> On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
>> HelloAdrian,
>>
>> in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
>>
>> Regards,
>>
>> Jacopo
>>
>> On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
>>
>>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>>>
>>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>>>
>>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>>>
>>> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>>>
>>> EntitySubtype
>>> -------------
>>> entityName*
>>> entitySubtypeId*
>>> description
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>
Re: Proposal: Entity Subtype Implementation
Posted by Adrian Crum <ad...@sandglass-software.com>.
Because I see the same potential for misuse if the subtypes were
implemented in Enumeration.
I will add implementation information to the description of the subtype
entities.
-Adrian
On 10/6/2012 8:42 PM, David E Jones wrote:
> If any single entity were to be used for types instead of one per type, why not Enumeration? And yes, that is what I did with the Mantle data model.
>
> Still, I agree with Jacopo... It is not worth the change repercussions for OFBiz. What you described is a problem with lack of research and/or experience, and I don't think what you described would be any more helpful.
>
> -David
>
>
> On Oct 6, 2012, at 10:19, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> So your opinion has changed...
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@hotwaxmedia.com%3E
>>
>> -Adrian
>>
>>
>> On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
>>> HelloAdrian,
>>>
>>> in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>> On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
>>>
>>>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>>>>
>>>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>>>>
>>>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>>>>
>>>> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>>>>
>>>> EntitySubtype
>>>> -------------
>>>> entityName*
>>>> entitySubtypeId*
>>>> description
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
Re: Proposal: Entity Subtype Implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <de...@me.com>
> If any single entity were to be used for types instead of one per type, why not Enumeration? And yes, that is what I did with the
> Mantle data model.
When I first played with OFBiz that's what I wondered about, why not all in Enumeration? Maybe simplistic, there are always pro and
cons, 2 sides of a coins, etc. (I don't know for you guys, but I often find myself in this situation)
The simpler the better, if you (application developer) have less choices to do you can focus on your "real" problems (your clients's
problems). That's what I still appreciate in OFBiz, even if it's not the case for types indeed. Changing them now seems a bit too
complicated, I agree.
Jacques
> Still, I agree with Jacopo... It is not worth the change repercussions for OFBiz. What you described is a problem with lack of
> research and/or experience, and I don't think what you described would be any more helpful.
>
> -David
>
>
> On Oct 6, 2012, at 10:19, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> So your opinion has changed...
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@hotwaxmedia.com%3E
>>
>> -Adrian
>>
>>
>> On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
>>> HelloAdrian,
>>>
>>> in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in
>>> the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>> On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
>>>
>>>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention
>>>> it deserves.
>>>>
>>>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype
>>>> that points to a *Type entity that contains valid subtypes.
>>>>
>>>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity.
>>>> That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented
>>>> product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment
>>>> process stopped working.
>>>>
>>>> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a
>>>> single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like
>>>> entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>>>>
>>>> EntitySubtype
>>>> -------------
>>>> entityName*
>>>> entitySubtypeId*
>>>> description
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>
Re: Proposal: Entity Subtype Implementation
Posted by David E Jones <de...@me.com>.
If any single entity were to be used for types instead of one per type, why not Enumeration? And yes, that is what I did with the Mantle data model.
Still, I agree with Jacopo... It is not worth the change repercussions for OFBiz. What you described is a problem with lack of research and/or experience, and I don't think what you described would be any more helpful.
-David
On Oct 6, 2012, at 10:19, Adrian Crum <ad...@sandglass-software.com> wrote:
> So your opinion has changed...
>
> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@hotwaxmedia.com%3E
>
> -Adrian
>
>
> On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
>> HelloAdrian,
>>
>> in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
>>
>> Regards,
>>
>> Jacopo
>>
>> On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
>>
>>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>>>
>>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>>>
>>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>>>
>>> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>>>
>>> EntitySubtype
>>> -------------
>>> entityName*
>>> entitySubtypeId*
>>> description
>>>
>>> What do you think?
>>>
>>> -Adrian
>
Re: Proposal: Entity Subtype Implementation
Posted by Adrian Crum <ad...@sandglass-software.com>.
So your opinion has changed...
http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@hotwaxmedia.com%3E
-Adrian
On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
> HelloAdrian,
>
> in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
>
> Regards,
>
> Jacopo
>
> On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
>
>> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>>
>> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>>
>> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>>
>> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>>
>> EntitySubtype
>> -------------
>> entityName*
>> entitySubtypeId*
>> description
>>
>> What do you think?
>>
>> -Adrian
>>
Re: Proposal: Entity Subtype Implementation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
HelloAdrian,
in my opinion it would be better to leave the data model as is, but improve the descriptions of the types (and documentation, in the form of comments to xml data) and also enhnce our utils to deal with types (the Product already has something in place).
Regards,
Jacopo
On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
> I mentioned this once before as part of another discussion, but I'm creating a new discussion so it can receive the attention it deserves.
>
> The Data Model Resource Book describes entity subtypes. OFBiz implements entity subtypes by adding a field to the supertype that points to a *Type entity that contains valid subtypes.
>
> The problem is users (and some developers) do not understand that pattern, and they add invalid subtypes to the *Type entity. That can cause things to break. As an example, I have a client who created additional ProductTypes (that actually represented product categories) and used those added ProductTypes for their products. Then they were puzzled why their order fulfillment process stopped working.
>
> I think what we need is an EntitySubtype entity to store the subtype data. Instead of multiple *Type entities, we would have a single EntitySubtype entity, and the supertypes will point to it. The supertype field could be called something like entitySubtypeId. The EntitySubtype entity will be clearly documented as to its purpose and proper use.
>
> EntitySubtype
> -------------
> entityName*
> entitySubtypeId*
> description
>
> What do you think?
>
> -Adrian
>