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
