OFBiz › OFBiz - Dev

[jira] Created: (OFBIZ-1332) Move extension field from PartyContactMech to TelecomNumber

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolas Malin (Jira)

[jira] Created: (OFBIZ-1332) Move extension field from PartyContactMech to TelecomNumber

Move extension field from PartyContactMech to TelecomNumber
-----------------------------------------------------------

Key: OFBIZ-1332
URL: https://issues.apache.org/jira/browse/OFBIZ-1332
Project: OFBiz
Issue Type: Bug
Reporter: Si Chen
Priority: Minor

It seems that the extension of a phone number is on PartyContactMech when it should be on TelecomNumber. We propose that we move it to TelecomNumber and change the related services, etc.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Closed: (OFBIZ-1332) Move extension field from PartyContactMech to TelecomNumber

[ https://issues.apache.org/jira/browse/OFBIZ-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David E. Jones closed OFBIZ-1332.
---------------------------------

Resolution: Won't Fix
Assignee: David E. Jones

This is intentionally designed to be this way.

A ContactMech can be shared by multiple parties, including a TelecomNumber. If multiple parties do share a TelecomNumber then it makes the most sense for the extension to be on the PartyContactMech, ie on the record that associates the party and the contact mech, and not on the contact mech itself.

The Data Model Resource Book vol 1 has more info on this.

> Move extension field from PartyContactMech to TelecomNumber
> -----------------------------------------------------------
>
> Key: OFBIZ-1332
> URL: https://issues.apache.org/jira/browse/OFBIZ-1332
> Project: OFBiz
> Issue Type: Bug
> Reporter: Si Chen
> Assignee: David E. Jones
> Priority: Minor
>
> It seems that the extension of a phone number is on PartyContactMech when it should be on TelecomNumber. We propose that we move it to TelecomNumber and change the related services, etc.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-1332) Move extension field from PartyContactMech to TelecomNumber

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533653 ]

Cameron Smith commented on OFBIZ-1332:
--------------------------------------

Hi David and Si. I was the one who originally proposed this, in a discussion with Si. I have to say I think the book (which I have and pore over regularly) is wrong here. It does not actually discuss or justify putting extension here, it just shows it in the diagram.

I think David's justification is reasonable, except for two points:
a. extension is a field specific to one subtype of ContactMech (TelecomNumber).
b. to be consistent with the placement of extension, "askForName" should also held at the level of PartyContactMech and not TelecomNumber as currently. In fact there is almost more justification for this because it maps to the more general concept of "ATT: John Smith" which people use on Postal Addresses, emails and Faxes

I would also make the point that, because of this, services like updateTelecomNumber would, IMHO, be better off not existing. They just clutter up the service reference screen, and take as much code to call as, for instance, doing the update by hand via the Entity Engine. So they add no value above the Entity Engine which is already easy to use and produces (almost) self-documenting code. Now a "business level" service such as "updatePhone" (which updated all the relevant fields in PartyContactMech, ContactMech and TelecomNumber for instance), would be another matter. It would roughly correspond to one system-side action in a business level use case (see Alistair Cockburn's excellent book on Use Cases). A good example of such a "business level" service would be postAcctgTrans.

Now, I think every project needs a benevolent dictator, and I think David's policy of following the Silverston book is good as a general rule. However in practice, every time we have used the Data Model for a real-world scenario, we have had to extend and adjust it - not a lot, but some!! At the end of the day, Mr. Silverston is an IT guy, not an accountant or logistics specialist, and sometimes it shows.

Anyway, I know my opinions are not shared by the majority of OFBizians, which is why I don't talk on the ML anymore, although I still read it. I think OFBiz is great, but the only products I have sold based on it, have required customization of the Data Model, so I can't contribute anything back, and I do not have the time to spend on lengthy discussions with core committers to justify them.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-1332) Move extension field from PartyContactMech to TelecomNumber

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533688 ]

David E. Jones commented on OFBIZ-1332:
---------------------------------------

A couple of quick notes (would be easier to respond on a mailing list to put answers in-line, but oh well, not that big of a message):

There are certainly some inconsistencies in the data model. I wasn't even aware there was an askForName on the TelecomNumber, and I'm not sure who added it (heck even I may have and forgotten it), but I agree that should go on the PartyContactMech, if it should exist at all, which with the party part of the PartyContactMech only makes so much sense... In general we don't always try to make sure fields that are specific to a certain type of an entity are not associated with the generic record, and in fact there are many examples of that. For many things it is too cumbersome and can perform worse and require more storage space (unless REALLY infrequently used) than a straight field on the main entity.

Also, the updateTelecomNumber service DOES have a point. In OFBiz ContactMechs are immutable. In other words, when they are "updated" they are not changed, the old one is expired and a new one created with the change.

As for the rest... to each his own I suppose. In general you might have a better experience if your emphasis is on something that can be more generic instead of satisfying a more limited and implementation specific set of requirements. Also, never underestimate the power of persistence... that's how most stuff gets done around here.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-1332) Move extension field from PartyContactMech to TelecomNumber

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534007 ]

Cameron Smith commented on OFBIZ-1332:
--------------------------------------

Thanks David, just a few quick responses.

1. I put the message here because it is much easier to read when I refer people back to it (sometimes I point guys in the team at OFBiz discussions as the best way of explaining why something is the way it is). Even with Nabble or whatever, mail conversations get terribly unreadable with all that copy-pasting.

2. I am aware of the OFBiz contact mechs being immutable, but I reckon my point about services still stands. An "updatePhone" service which took /all/ the info of the phone, and 'updated' the relevant entities (really, as you say, expired and recreated them), would be a lot more useful, instead of updateTelecomNumber.

3. Much as I prefer things to be generic wherever possible (like most programmers, I always have an urge to factor out commonalities), I cannot sell something which does not 'click' in the mind of the client. However I think an 'updatePhone' service (and more broadly, the philosophy underlying it about the granularity of services), would be completely generic and is certainly not implementation-specific. In other words, I don't think my experience is related to the specificity or not of what we are implementing.

4. Persistence. Assuming you mean "keeping at it" rather than ORM ;-) I agree. I also work 6x12h days every week, so its often a battle between persistence and sleep.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.