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. Regards, Jacopo > Regards > Scott > > On 30/05/2012, at 7:23 PM, Adrian Crum wrote: > >> From what I recall, the idea is for a customer service person to ask how >> long the customer has been at that address, and the customer would respond >> with a time duration of months or years. There are no exact dates in the >> scenario. >> >> I would recommend using a TimeDuration to calculate a fromDate based on the >> current date. So, the CSR enters months or years at current address, and a >> service calculates PartyContactMech.fromDate based on that information. >> >> -Adrian >> >> On 5/30/2012 12:34 AM, Adam Heath wrote: >>> I noticed the 2 fields in the subject, but didn't actually recoginize >>> them(I've been using ofbiz for a *long* time). I did a big of >>> digging, and noticed that those fields were added to the model in >>> 2006-05-04(1), and were first utilized when anonymous checkout was >>> added 2006-11-28(2). There has been no real use of the 2 fields since >>> then. >>> >>> Why do they have to exist? Why can't DATE_TRUNC or some other sql >>> function be used? Or normal Timestamp manipulation on fromDate/thruDate? >>> >>> 1: http://svn.ofbiz.org/svn/ofbiz/trunk@7513 >>> 2: https://svn.apache.org/repos/asf/incubator/ofbiz/trunk@479879 >
