On 06/01/2012 12:29 PM, Adrian Crum wrote:
On 6/1/2012 6:42 AM, Jacopo Cappellato wrote:
On Jun 1, 2012, at 6:44 AM, Scott Gray wrote:
The only problem there would be that the information would need to be
known when the record was created since fromDate forms part of the
primary key. It's entirely possible that the user could create the
contact mech themselves via the ecommerce app and then later an
external service runs to gather that type of information from an
authoritative source for fraud detection purposes. Hypothetical but
entirely conceivable I would imagine.
There is also a difference between validity dates in the system
(fromDate/thruDate) and the information about the number of
years/months the contact was valid in the real world.
I have to admit I was not aware of these 2 fields and at first I was
inclined to remove them, but after reading the use cases from Adam and
Scott I think it makes sense to leave them, or replace them with
sinceYear (or similar/better name) where the use can store the year
(e.g. 2003) the contact mech was used the first time and a sinceMonth
field (Jan, Feb...) to be used optionally if sinceYear is set.
sinceYear or fromYear would make more sense than the current fields. The
existing fields are meaningless without a time reference.
Very good point. Which means as currently implemented they at all
useful. So, it might make sense to redo it, as how could we be
backwards compatible?
But this time, let's try to find proper use cases. One has been given
in this thread already(I think it's not needed, however, and fromDate
can be made to handle it).
In fact, the fields are wrong anyways. Just invent a new
ContactMechPurposeType.
