Just a reminder-Aliya is in the field (without any internet connectivity) and will not be able to respond for a few more days.
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Lee Sent: Wednesday, November 28, 2007 8:29 AM To: Developer Subject: Re: [Mifos-developer] issue 1512 persistent object equals/hashCode-data model clarification needed I think the ball is now back to Aliya to clarify the data model. Tom - you're correct on what I'm asking. I'm asking for clarification because Aliya's previous reply seems to refer to actual Loan Accounts, rather than Loan Products. So I want to double check just to make sure. On Nov 27, 2007 11:58 AM, Tom Bostelmann <[EMAIL PROTECTED]> wrote: Ah, okay. So basically, the UI doesn't allow you to create multiple "relationships" [LoanOfferFeesEntity] to the same fee. So, you're wondering if that means that changes whether or not two instances of LoanOfferFeesEntity with the same Fee are, in fact, distinct. Is this correct? Aliya, you may correct me on this, but I think that it doesn't. Even though the UI doesn't fully support the data model, I think the data model needs to support two distinct relationships to the same fee. Does that answer your question, Sam? (good question btw ;) -Tom On Nov 26, 2007 9:53 PM, Sam Lee < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: Tom / Aliya, Let me try again. What I'd like to get a clarity is whether LoanOfferFeesEntity has a business key or not. The answer will impact the correct equals() / hashCode() implementation for the Java object . I'll try to map the Java class in question to the actual UI and database tables to make sure we're on the same page. To the extent I could map, it looks like LoanOfferingBO refers to a Loan Product (rather than individual loan account). The UI (and the current ER data model) seems to imply a LoanOfferingBO (aka loan product on UI) can be associated with a FeeBO (aka Fee type on UI) at most once. The java classes in this context include: |---LoanOfferFeesEntity(id6)---| LoanOfferingBO(id1) -- ---- FeeBO(id2) |---LoanOfferFeesEntity(id5)---| 1. Could someone reconfirm if my understanding below is correct? 1a. A LoanOfferingBO (maps to prd_offering table + loan_offering table) instance maps to a Loan Product (rather than a Loan account) as in the the main object to be created in the Loan product definition screen: http://test.mifos.org:8085/mifos/loanproductaction.do?method=load&record OfficeId=1&recordLoanOfficerId=1&randomNUm=-1022391167983022447 1b. A LoanOfferFeesEntity (map to prd_offering_fees table) instance maps to the association between a fee type and the loan product (basically the fees section of the Loan Product definition screen above) 1c. A FeeBO (maps to fees table) instance maps to individual Fee Type. 2. If my understanding as in (1) is correct, 2a. Mifos web UI does not allow a loan product to be associated with a fee multiple times (it's a simple multi-selection form). 2b. Using the example Tom provided earlier on, I don't see anywhere in the loan product definition screen (loanproductaction.do) allowing the loan officers to define that a certain loan product require two consultation visits (and hence two consultation visit fees). 2c. in ER term, the LoanOfferFeesEntity (backed by prd_offering_fees table) has a business key of (product_id, fee_id). Thanks for the clarification in advance. Thanks. - sam On Nov 24, 2007 9:11 AM, Aliya Walji <[EMAIL PROTECTED]> wrote: >> Here's my attempt at a business example (Aliya/Emily/Beth/Amy/... please step in to correct me if I'm wrong): I think you're correct, Tom, on the functionality. According to the FS "A particular fee instance can be applied multiple times to a customer account". Checking out this functionality in the product also verifies this behavior. I can create a loan account with two of the same fee type applied to the account. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Bostelmann Sent: Thursday, November 22, 2007 5:01 AM To: Developer Subject: Re: [Mifos-developer] issue 1512 persistent object equals/hashCode- data model clarification needed This is a great question. The additional test fails - which it should because LoanOfferingFeesEntity (bad use of plural 'Fees' in name aside) represents an instance of a fee that is associated with the loan product. Here's my attempt at a business example (Aliya/Emily/Beth/Amy/... please step in to correct me if I'm wrong): An example situation could be where the loan officer sets up a fee to cover the costs of providing a consultation visit (this is represented by the FeeBO). The loan officer has decided that a certain loan product requires two such visits (two instances of LoanOfferingFeesEntity using the same FeeBO). Therefore there should be two different instances of the same fee associated with this loan product. Does that make sense? On Nov 14, 2007 11:12 PM, Sam Lee <[EMAIL PROTECTED]> wrote: Hi, I'm looking into issue 1512, the equals/hashCode issue identified from findbug. To ensure I understand the business requirement / data model, could someone clarify whether the following is true or not? 1. For each loan product, it may be associated with multiple fees. (I guess fees the product could apply) 2. However, each loan product will be associated with the same fee at most once. In other words, in mysql, table prd_offering_fees should have a unique constraint on (prd_offering_id, fee_id) You can also see the attached patch on LoanOfferingBOTest that reflects the above assumption. Or you can see the actual test right below (rather than going through the patching). - sam A new test method in LoanOfferingBOTest.java (equivalent to the attached patch) public void testBuildloanOfferingWithDuplicateFeeXXX() throws SystemException, ApplicationException { createIntitalObjects(); Date startDate = offSetCurrentDate(0); LoanOfferingBO loanOffering = new LoanOfferingBO(TestObjectFactory .getContext(), "Loan Offering", "LOAN", productCategory, prdApplicableMaster, startDate, interestTypes, new Money("1000"), new Money("3000"), 12.0, 2.0, 3.0, (short) 20, (short) 1, (short) 12, false, true, false, frequency, principalglCodeEntity, intglCodeEntity); FeeBO fee = TestObjectFactory.createOneTimeAmountFee("Loan One time ", FeeCategory.LOAN, "100", FeePayment.UPFRONT); LoanOfferingFeesEntity loanOfferingFees1 = new LoanOfferingFeesEntity(loanOffering, fee); loanOffering.addPrdOfferingFee(loanOfferingFees1); // another fee for the proudct: which refers to the same fee // as the one above LoanOfferingFeesEntity loanOfferingFees2 = new LoanOfferingFeesEntity(loanOffering, fee); loanOffering.addPrdOfferingFee (loanOfferingFees2); assertEquals("sam: I believe the business requirement is that the loan should not have fees that are essentially the same.", 1, loanOffering.getLoanOfferingFees ().size()); assertEquals("sam: I belive these two offering fees are considered identical from business requirement", true, loanOfferingFees1.equals(loanOfferingFees2)); } ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
