Hi Pierre,
Inline...
Le 13/11/2021 à 14:45, Pierre Smits a écrit :
Thank you, Gil, for referencing various pre-cursors to this discussion.
As some may experience a case of TLDR given the lenghty threads in your
listing of references, I will try to clarify the issue within its context.
*** Does a user experience one or more issues with the 'remove'
functionality regarding the PartyRole entity? ***
Yes, they do. The user experiences an error message when he/she/they
removes (meaning delete) an PartyRole in either the party component or in
webtools.
This should be undesirable from the project's perspective. Hence Jacques
remark in [1].
As you somehow quoted me (I guess you speak about my 1st comment in
OFBIZ-5959), I want to mention the end of that comment:
<<This still needs more thoughts and checks on my side...>>
And my next comment follow comments from other,notably from the late Adrian:
<<I think Adrian's argument about PartyRole fks everywhere is serious. As says
Nicolas, this endeavour seems risky. What would be the alternatives?>>
I think it's enough to clarify my thoughts at that moment.
*** What is the root-cause of this issue? ***
This is two-fold:
1. functional: because in various Party and Role setting forms ( in
various applications other than party and webtools) there is no limit to
which party can be paired to what role. Which is then taken by the
ensureParty as parameters and persisted as a PartyRole record.
2. technical: because of the PartyRole being used as a sql foreign key
constraint in various other entities, and
*** Can the issue regarding the PartyRole be resolved technically? ***
It is not impossible, so yes. And preferable, as Jacopo points out, without
introducing new bugs.
Addressing aspect #1, listed above, will reduce the number of erroneous
record going into the PartyRole table.
And evaluating each of the entities relating to aspect #2 whether there is
an absolute (as in set-in-stone) necessity for having the sql foreign key
constraint on PartyRole.
When both are addressed, then the risk of introducing enhancements to the
PartyRole (and its associated forms, requests and service functions) is
minimised.
With my recent experience ending by a revert, I tend to agree, we can try that. But something is unclear to me. What is an "erroneous record going
into the PartyRole table", how to limit them? Before doing anything this needs to be defined.
For your second proposition, I think we can remove all FKs going to PartyRole,
using one-nofk in relations for instance, as proposed David.
As Scott wondered (I think he never proposed that) an even more audacious
endeavour would be to remove PartyRole altogether.
Jacques
Met vriendelijke groet,
Pierre Smits
*Contributing to* Apache OFBiz<https://ofbiz.apache.org/> since 2008 (without
privileges)
Contributing to the ASF since 2006
*Apache Directory<https://directory.apache.org>, PMC Member*
On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:
Thank you Gil.
In my opinion the *Role data model and the way OFBiz leverages it and the
*Relationship data model are not ideal (some of the issues have been
mentioned in the various threads referenced by Gil) but I don't feel that
this specific enhancement is relevant enough to justify the risk of
introducing new bugs, issues and regressions.
Jacopo
On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:
Hello,
I'm starting a new thread to discuss with the community about an
Improvement that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was conclude by
a lazy consensus not to implement PartyRole lifespan into OFBiz.
Recently, this improvement was discussed again in Jira [3], and partly
commited, before being reverted when big blocking side effect where
discovered.
A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto
PartyRole entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the
community consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we
need to organize or if we need to close pending Jira with reference to
this
discussion ?
Thanks,
Gil
[1]https://issues.apache.org/jira/browse/OFBIZ-5959
[2]
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3]https://issues.apache.org/jira/browse/OFBIZ-5980 (
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
)
[4]
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
