Hi Chris, (all)
hmmm... I was hoping that your comments were motivated by a careful
review of the OFBiz existing data model and processes, not by general
and abstract assumptions of how you think an agreement data model should
be designed.
Hopefully now we are not in the process of drafting out the agreement
data model from scratch (and the OFBiz data model in general): the data
model is already in place (and it's very very good, even if it is not
perfect), we have many users running their applications on it, and now
we are trying to implement/complete the processes based on it and
sometimes, while building them, we refine the data model itself.
This is the current status of the OFBiz project and we should all be on
the same track: I really think it would be a bad thing for the project
(confusion for users/developers, slow down development, backward
compatibility issues) if we were to assume that, every time a new
feature is discussed, it is a good chance to re-implement the OFBiz data
model starting from some very different abstract data model we have in mind.
We are working on OFBiz an we should focus on OFBiz, limiting our
comments on what we know of OFBiz.
And finally, as regards the existing OFBiz data model and features, I
think it is wise to limit our remarks based on real use cases we are
facing with OFBiz and not on the use cases we could imagine that could
happen: by my experience, when we try to forecast each and every use
cases we'll be however missing many of them - the real ones ;-) - and we
will spend a lot of time writing code to handle useless scenarios (that
no one will use, test, implement).
Sorry for the long post,
Jacopo
Chris Howe wrote:
I've just looked over the Agreement entity and the
"history" of it in svn. I can completely see why
we're coming at this from different perspectives.
Agreement.productId has ALWAYS been there. I'm
shocked. I assumed Agreement was meant to be generic
(there I go assuming again). If Agreement.productId
exists, the Agreement entities are anything but
generic. If productId is a foreign key, the Agreement
entities are not designed to support employment
agreements, order agreements, etc. and technically,
not even pricing lists (as that would be require a one
to many relationship between agreements and products,
but this is a one to one relationship).
Hopefully, by the end of the week I'll be finished
with the changes I'm making to the party relationships
http://issues.apache.org/jira/browse/OFBIZ-149
(for my local use, but will be available in JIRA when
I'm done, and if there's any interest I'll create a
patch that replaces the current party relationship
stuff)
After that I'd be more than happy to
collaborate/develop a generic Agreement model that
will be easier to model and integrate with other
generic models as we'll end up needing it to be
generic in our local implementation.
