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/

Reply via email to