Mailing-List: contact jdo-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: jdo-commits@db.apache.org
To: jdo-commits@db.apache.org
Subject: =?iso-8859-1?q?=5BApache_JDO_Wiki=5D_New=3A__XMLMetadata?=
Date: Wed, 12 Jan 2005 19:40:19 -0000
Message-ID: <20050112194019.89548.87989@minotaur.apache.org>

   Date: 2005-01-12T11:40:19
   Editor: MichelleCaisse
   Wiki: Apache JDO Wiki
   Page: XMLMetadata
   URL: http://wiki.apache.org/jdo/XMLMetadata

   no comment

New Page:

=3D Chapter 18 Test Coverage Notes =3D
Chapter18TestCoverageNotes
=3D Notes from jdotck weekly meetings on xml metadata =3D

November 19:

Agenda:

1. Discuss present Company model to see if it is suitable for use for mappi=
ng tests.
2. Review all metadata elements/attributes and map against Company model.
3. Take a look at Chapter 15 examples.

It looks like the Company model is suitable for many of the mapping tests, =
but some of the extended mapping elements will need either their own mappin=
g/schema or an entirely new model. We reviewed the model along with the met=
adata to see how well the model met the requirements.

To support embedded sub-classes, we need to define a different schema:
add subclass for US Address
postal code for US
embedded derived class
is embedding a common enough case to put in separate schema? Probably not. =
We concluded that we should have a separate model/mapping/schema to handle =
embedded subclasses. The Company model is sufficient for the basic embeddin=
g/serialization.

To support multiple relationships between the same model classes, we will a=
dd fundingDepartment, fundedEmployees to the Employee/Department model.

To support subclassing of one-one relationships, and multiple one-one relat=
ionships between different model classes, we will add MedicalInsurance, Den=
talInsurance as subclasses of Insurance and have one-one relationship betwe=
en Employee and medicalInsurance and between Employee and dentalInsurance.

More types should be added, but we agreed to add String[ ], Collection<Stri=
ng> to another model. These are only a small part of a list of extended typ=
es that need model/mapping/schema support.

Company is mostly used by query and extent tests.

May want to use Company for generating schema. This involves adding enough =
information to generate schema from the mapping (table, column, index names=
, jdbc types) but we want to avoid putting sql-types into the mapping, as t=
hese are database dependent.

Must support schema as modified by vendor. The TCK needs to specifically st=
ate that the schema distributed with the TCK can be changed at will. We als=
o need to specify which parts of the mapping can be changed.

We need to define navigate test as a base test that can populate a database=
 with a specific set of test data and verify that the objects were properly=
 stored.

create graph of company schema using input file to specify the objects and =
fields
commit
get new pm, start tx
get company by id
navigate to entire graph.
verify contents of the datastore against the input file.

We need separate schema, object model, mapping for persistent interface typ=
es. We won't add persistent interfaces to the Company model.

Testing null fields. Add middle name as nullable String to Person; have two=
 Person constructors one with middle name one without

We should look at Chapter 15 examples to see if we can rewrite them to use =
the Company model and mapping. Most test organizations would at least verif=
y that the examples compiled and parsed. The easiest way to do this would b=
e to use examples from the Company model.

We got about halfway through the list of elements and attributes. We will c=
ontinue at the next conference call.

Since next week is Thanksgiving, we will not have a TCK conference call. Bu=
t we should meet the following Friday. I'll send out an announcement of the=
 meeting.

Craig

December 3:

Attendees:

Michelle Caisse, Victor Kirkebo, Michael Bouschen, Patrick Linskey, Craig R=
ussell.

Reviewing the Chapter18Test.html document, starting with foreign-key elemen=
t.

Not clear whether we need to or how we are supposed to test foreign-key del=
ete-action or update-action. Need a spec update to clarify exactly what the=
se attributes are. Patrick was volunteered to provide a reference to the Ko=
do documentation that describes what they do with these attributes.

Underspecified dependent objects' life cycle behavior. Should transition to=
 deleted if reference is nullified or removed from a collection. This topic=
 interacts with foreign-key delete-action.

Embedded element needs clarification 18.13.1. Kodo uses collection embedded=
 element to describe separate table with elements in it, whereas Craig thou=
ght that the spec clearly called out that embedded elements are supposed to=
 be mapped to the same table as the rest of the fields.

We will resume the discussion next week at the map element.

Craig

December 10:

We completed reviewing the attached document as a base for deciding how muc=
h work is involved in writing the TCK tests for the metadata chapter.

The next steps are to write a specification for the base mapping metadata t=
est, and to update the document to provide more detail on the kind of test/=
mapping/metadata needed for the tests that cannot be done with the "Complet=
eness Test".

We discussed Matthew's proposal to add a Map to the Company model, and agre=
ed that a simple map of primitives made sense for the model, but more compl=
ex types (pc key, primitive value; primitive key, pc value; pc key, pc valu=
e) should have its own model and test.

We will meet again this coming Friday, same call number, same time 9:00 AM =
PST.

866 230-6968 294-0479#
865 544-7856

This will be the last meeting this year, as the following Friday is Christm=
as Eve.

Craig =


December 17:

Javadogs,

Agenda:

1. Review Spring Framework BeanFactory approach to testing mapping.

a. Issue: how to stop deepEquals in case of circular references, e.g. an Em=
ployee is her own manager.

b. Issue: BeanFactory creates instances of LinkedHashSet which are not supp=
orted by FOStore.

c. Issue: How to create different xml files (data load and metadata) by cre=
ating diffs. We expect that around 100 different files will be needed, of w=
hich a substantial portion will be identical to the base mapping files. We =
want to just look at diffs not the entire mapping file (to avoid duplicatio=
n of bugs in the mappings).

d. Additions to EqualityHelper (renamed DeepEqualityHelper):

Compare two doubles, floats, "close enough". Compare BigDecimal for equalit=
y ignoring scale.

class EqualityHelper {
boolean deepEquals(DeepEquality me, DeepEquality other);
boolean deepEquals(Collection, Collection);
boolean deepEquals(Map, Map);
boolean shallowEquals(Collection, Collection);
boolean closeEnough(Object, Object); // other variants tbd
boolean closeEnough(double, double); // others needed?
boolean equals(Object, Object);
}

Note that closeEnough needs to compare two numbers and check that they are =
within some percent of each other. An absolute epsilon is not sufficient. F=
or example, closeEnough(0.001, 0.002) should return false but closeEnough(1=
000000.001, 1000000.002) should return true.

interface DeepEquality {
boolean deepEquality(Object other);
}

2. Think about this: should we use the same strategy for queries? That is, =
define the persistent object graph via BeanFactory xml and run queries agai=
nst it? Queries are probably the biggest part of the functionality of mappi=
ng that needs testing.

Craig =