On Sep 3, 2006, at 3:28 PM, 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).
What are you talking about? I don't see how this could be true at all. Just because a field is on an entity doesn't mean it can't be null, even if it is a foreign key. When all fields in an fk are null the foreign key constraint is ignored.
I may not be understanding what you're trying to express or what sort of limitation you're seeing, but if this were coming from a different source it's the type of thing I'd label and file away as a baseless FUD attack on the project... ;)
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)
Yes, please do submit it, but please also respect the feedback that this will most likely never replace the current party relationship stuff, especially not if the various objections to it are not addressed where it would not sufficiently replace existing functionality.
The way to submit such patches is as a new feature, not a replacement for an extremely commonly used, understood, and accepted feature.
-David
