Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: binary
Mime-Version: 1.0
From: Andy Jefferson <andy@jpox.org>
To: jdo-dev@db.apache.org
Subject: TCK : Map tests
Reply-To: andy@jpox.org
Date: Sun, 23 Oct 2005 10:34:34 +0100
Message-Id: <20051023093255.33B2F10FB2B0@asf.osuosl.org>

Hi Michelle,

I've been through the issues with the various TCK Map tests, and have the 
following comments :-

1. The key-type, value-type are currently being defined as things like Object, 
String, SimpleClass whereas the Collection tests use fully-qualified names. 
While this may be intentional to check the qualification of namings it does 
raise the issue of what an implementation is supposed to do wrt class namings 
when not fully-qualified. I refer to spec section 18.4.1
<spec>
The element-type attribute specifies the type of the elements. The type name 
uses Java rules for naming: if no package is included in the name, the 
package name is assumed to be the same package as the persistence-capable 
class. Inner classes are identified by the "$" marker.
</spec>

so in the case of the TCK tests, since there's no package name we prepend the 
package of the class being persisted. This means that the String, Object 
fully-qualified names get messed up since they aren't in the same package as 
the class. I suggest that these be fully-qualified in the MetaData as 
"java.lang." so that a JDO implementation can find the correct class. You can 
leave the "SimpleClass" as they are currently since those will be correctly 
identified.

2. The Map tests include embedded interfaces and embedded Object fields. The 
Collection tests do *not* do this. I personally consider support for embedded 
Collections/Maps of reference types (Object, interface) as an optional part 
of JDO since it is of minority interest in the user domain (in the same way 
as supporting inherited embedded collections of inherited objects should be 
optional). Really it ought to have PMF parameters to define if the 
implementation supports it (something like 
javax.jdo.option.EmbeddedCollectionOfReferences, 
javax.jdo.EmbeddedMapOfReferences), and so the TCK can act accordingly. This 
is the one Map mapping that JPOX doesn't support.

3. JPOX also supports Maps where there is no join table and the key is a field 
in the value class. Is there a TCK test for this ? You can see this 
relationship defined here
http://www.jpox.org/docs/1_1/relationships_1_N_map.html#fk_uni


-- 
Andy