Hi,

JDO-69 describes a test error that occurs when the test attempts to make
an embedded class persistent. The solution that I propose is an
extension of one we previously implemented for tearDownClasses  In this
case, I propose adding to CompanyModelReader an array containing the
embedded classes for the model and a boolean method isEmbedded(Class).
In QueryTest, I check if the class is embedded before making it
persistent.  See the attached patch.

The concern that I have about this solution is that it only works for a
particular mapping of the company model.

The proposed solution fixes most of the 17 errors caused by this issue
under application identity.  Under datastore identity, the affected
tests produce a different error --  the implementation expects an
identity field for the embedded Address class (JDO-83).

-- Michelle

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Hi Michael,

I've assigned JDO-69 to you.

-- Michelle

Craig Russell wrote:

> Hi Michelle,
>
> Michael and I were talking this morning about a related issue with
> reading an object model and making some of the instances persistent.
> The test case we were talking about was the CompletenessTest but the
> results were relevant.
>
> What we decided as an approach is to define another object in the bean
> xml file called "root". This object is a List that contains all of the
> objects to become persistent. In the case of the CompletenessTest with
> no relationships, we need this to be able to instantiate instances of
> Company, Department, PartTimeEmployee, FullTimeEmployee,
> MedicalInsurance, DentalInsurance, and Project and individually
> persist them and compare them. We don't need to persist the Address
> because these are embedded.
>
> We discussed using this same approach for the QueryTest as well.
> Michael said he would look into modifying the query test to use the
> same pattern, and see if both tests could use the same company.xml
> input files.
>
> Considering persistence by reachability, the only objects needed in
> the "root" list is the root of the connected objects. I think in the
> case of the query test, it is the single object "dept1" that is in the
> "root" list. I suppose it can't hurt to have emp1, emp2, and emp3 in
> the root list as well, but it is only needed if the implementation has
> a bug in persistence by reachability.
>
> I don't think we need an "isEmbedded" feature in the CompanyModelReader.
>
> Craig
>
> On Jul 12, 2005, at 2:47 PM, Michelle Caisse wrote:
> 
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>

[ Post a follow-up to this message ]