Posted by
Si Chen-2 on
URL: http://ofbiz.116.s1.nabble.com/how-about-adding-a-paymentMethodName-to-PaymentMethod-tp169026p169032.html
On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
> Let me explain it differently. The PaymentMethod
> entity is an entity of convenience, not an entity that
> describes anything.
No, it's an entity that describes a payment method. There are some
payment methods which have additional information specific to them,
but then again there may be some other payment methods which don't
require additional entities.
>
> So now we add description. But, there's already a
> description (firstName, lastName) for Person and a
> description (groupName) for Corporation. This is
> information that is likely to change and we will need
> to keep track of it in multiple locations when it is
> unneccesary.
>
But there is no description on CreditCard, EftAccount, nor is there
an equivalent field. So this is not the case right?
> So, there's no benefit of adding the description, but
> you've added the possibility of the nonnormalized data
> to be inconsistant. Does that make a good data model?
Actually there's a real benefit. If I just want to get the
description of a PaymentMethod and it's on the PaymentMethod, it's
very easy. If I have to .getRelated based on the type of the
PaymentMethod to another entity, it's a mess.
>
>
>
> --- David E Jones <
[hidden email]> wrote:
>
>>
>> Huh?
>>
>> Chris Howe wrote:
>>> It may apply to all payment methods (I'm not
>> really
>>> sure that it applies to all current payment
>> methods,
>>> much less ALL that may exist), but it does not
>>> describe the payment method. It describes the
>> payment
>>> method's child so it should go in the entity that
>> it
>>> is describing.
>>>
>>> Following through with the approach of putting the
>>> field in PaymentMethod entity puts you in the
>> position
>>> of modifying the data to fit the data model
>> instead of
>>> keeping the data model flexible enough to fit the
>>> data.
>>>
>>> --- Si Chen <
[hidden email]>
>> wrote:
>>>
>>>> I disagree. This is a descriptive note that
>> applies
>>>> to all
>>>> PaymentMethods so why put it in the child
>> entities.
>>>> If you had a
>>>> parent class which had a field that all inherited
>>>> classes should
>>>> have, shouldn't be in the parent class?
>>>>
>>>>
>>>>
>>>> On Jun 28, 2006, at 1:35 PM, Chris Howe wrote:
>>>>
>>>>> "Bank A general account" does not describe the
>>>>> PaymentMethod, it describes the credit card, the
>>>>> company account, the gift card, etc so that
>> field
>>>>> should go on the CreditCard, etc entity. Now if
>>>>> you're using it as an alias for the Payment
>>>> Method,
>>>>> then you should create a PaymentMethodAttribute
>>>> entity
>>>>> and make a relationship between the two.
>>>>>
>>>>>
>>>>> On a side note. I've noticed a couple of fields
>>>>> getting added onto entities in svn that are
>> quick
>>>>> fixes to gain functionality but cause a loss of
>>>> the
>>>>> entity's meaning. PaymentMethod.partyId is one
>>>> that
>>>>> quickly comes to mind.
>>>>>
>>>>> --- Si Chen <
[hidden email]>
>>>> wrote:
>>>>>> Hi everybody.
>>>>>>
>>>>>> What do you think of adding a field
>>>>>> "paymentMethodName" to
>>>>>> PaymentMethod, so a company can identify that
>>>> method
>>>>>> A is "Bank A
>>>>>> general account", etc. etc.
>>>>>>
>>>>>> Si
>>>>>>
>>>>
>>>
>>