Proposal: Entity Subtype Implementation

[Adrian Crum-3]

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

[Olivier.heintz]

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

[Olivier.heintz]

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

[Adrian Crum-3]

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

[Scott Gray-2]

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

[Adrian Crum-3]

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
>

[Jacopo Cappellato-4]

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
>

[Adrian Crum-3]

So your opinion has changed...

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@...%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
>>

[David E. Jones-2]

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 <[hidden email]> wrote:

> So your opinion has changed...
>
> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@...%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
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> 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 <[hidden email]> wrote:
>
>> So your opinion has changed...
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@...%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
>>

[Adrian Crum-3]

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 <[hidden email]> wrote:
>
>> So your opinion has changed...
>>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3C82330F5C-3938-487E-98AE-FFEE0C8761D3@...%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

[Jacopo Cappellato-4]

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@...%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
>>>
>

[Adrian Crum-3]

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@...%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
>>>>