Tom,
I think I know what you mean but just to make sure: are you saying
1. A relationship such as the following is valid? (a poorman ascii art)
|---LoanOfferFeesEntity(id6)---|
LoanOfferingBO(id1) -- ---- FeeBO(id2)
|---LoanOfferFeesEntity(id5)---|
2. If (1) is correct, are we also saying that (in ER term), the
LoanOfferFeesEntity (backed by prd_offering_fees table) has no business
key?
Thanks.
- sam
On Nov 21, 2007 3:01 PM, Tom Bostelmann <[EMAIL PROTECTED]> wrote:
> 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/