On Mar 10, 2009, at 1:42 AM, Hans Bakker wrote:
see below...
On Tue, 2009-03-10 at 01:15 -0600, David E Jones wrote:
Aside from it being easier to find the data when they are in these
entity fields (which are always there, don't require a join/view or
additional find, etc), not all of the data is available in the *Role
entity.
The fields on the CommunicationEvent entity have 3 bits of
information
for each party:
1. the fact that it is the from or to party
2. the ID of the from or to party
3. the role (like customer, employee, whatever) of the from or to
party
that is the exact info in the communicationEventRole....
How would you model #1 and #3 in CommunicationEventRole? You could use
a role that specifies from/to (which is a bit of a hack, ie that isn't
technically a "role"), or you could specify a role that describes
their actual role. Doing both would require 2 records with no way to
match them up other than through the partyId... and what if other
there are other roleTypeIds for that party, etc?
In other words, the structures are NOT equivalent. The biggest issue
that I have is that for these fields which are common things to query
by, display, etc it is nice not to have to do a view/join or
additional query to get the data...
And yes, it would be nice if other's voiced their opinions. BTW, the
data in these structures should not be duplicated and introduce
redundancy. If the partyIdFrom/roleTypeIdFrom fields are populated the
same data should not be in CommunicationEventRole records.
-David
On Mar 10, 2009, at 12:56 AM, Hans Bakker wrote:
As I said all that data is duplicated in the roles entity...
the role tells where it comes from, it can more than one destination
and
can have many more participants in various other roles.....
In the case of the communication event it even contains the
contactMech
used and status per participant.....vary important in an email
communication event.
The partyIdTo is even confusing if it was an email send to several
persons....
i also do not say it is applicable to other entities, only for
communication event...
Everywhere the entity Communicationevent is used it needs to it
replaced
by the CommunicationEventAndRole view to have the same info.....
anybody else any opinions?
Regards,
Hans
On Tue, 2009-03-10 at 00:38 -0600, David E Jones wrote:
What about all the other places where this pattern is used, ie
where
there are partyId and/or roleTypeId fields along with a *Role
entity?
There are probably dozens of them...
The main idea of these is to have the most common, and often
necessary, roles represented on the main entity.
Also, if we remove these fields how would we know which is the from
and to, along with allowing various different roles for the from
and
to parties?
-David
On Mar 10, 2009, at 12:11 AM, Hans Bakker wrote:
I would like to propose to depreciate the fields "partyIdFrom and
PartyIdTo and related roles and contact mech in the communication
event.
All these fields fields are duplicated in the
communicationEventRoles.
if no objections i will slowly phase them out...first in the
entity
reference and then in forms and screens.
--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....
--
Antwebsystems.com: Quality OFBiz services for competitive rates
--
Antwebsystems.com: Quality OFBiz services for competitive rates
