On Mar 10, 2009, at 2:53 AM, Hans Bakker wrote:
Hi David,
thanks for the time to provide an extensive answer.
The problem i have with these fields is actually mostly showing when
the
communication event is used as an email but also in the other
commEvent
types.
What you describe below is theoretically completely true, however the
reality is different.
That there's what I like to call a "logic trap".
On an email, the roles of the participants as you describe them, are
normally not entered and that is why we have roles like "originator"
"recipient" and "carbon copy".
If we were to model this information literally I wouldn't recommend
using the CommunicationEventRole entity, as it means something
different. What you are describing here is the addresses on the email,
and perhaps the Party for each (if there is a Party for the given
address in the system).
In that case an email address (a contactMechId) would be required and
part of the PK but the partyId would be optional, and not part of the
PK.
That doesn't sound like a CommunicationEventRole to me...
Do you state that you are a 'customer'
when you write an email to your webshop if you are perhaps also
employed
by them?
Even more the need for identifying the role for that particular
communication. It can be helpful to know that a party that is both a
customer and an employee is acting as a customer or employee for a
particular communication.
I even doubt when the communication event is a phonecall or actually
any
other event type, even then the 'real' roles are not used....
That is why i said that the info is in the communicationEventRoles.
So what do we do, keeping the system OK in theory or do we make it
practically working?
Yeah, back to the "logic trap". The implied assumption is that using
the CommunicationEventRole entity is the only practical solution. If
you start from there chances are you'll end up there, hence the term
"logic trap".
It's helpful to talk about specific data you want to model, as you
started to above and that I tried to communicate back to you and
expand a bit there. If that isn't what you're trying to model, we
should maybe start with establishing what it is that you're trying to
model and then come up with the best structure for it, perhaps an
existing one and perhaps not.
-David
On Tue, 2009-03-10 at 01:57 -0600, David E Jones wrote:
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
--
Antwebsystems.com: Quality OFBiz services for competitive rates
