db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jordan" <davej...@bellsouth.net>
Subject RE: Negative VOTE Issue 138: Define optional features for PMF
Date Mon, 13 Feb 2006 21:38:30 GMT
That works for me. I just think we have a much stronger standard if we have
more required collections in JDO 2.0. The more collections we have
standardized, the more we have standardized compared to other APIs (e.g. EJB
3.0 and Hibernate), the better off JDO is. Developers wanting the
portability of JDO want the guarantee of a collection's support among all
implementations before they are willing to put it in their object models.
Each collection that is added as required makes the standard stronger.

David Jordan

 

-----Original Message-----
From: Craig.Russell@sun.com [mailto:Craig.Russell@sun.com] 
Sent: Monday, February 13, 2006 4:30 PM
Cc: 'JDO Expert Group'; 'Apache JDO project'
Subject: Re: Negative VOTE Issue 138: Define optional features for PMF

 

Hi David,

 

What would you specifically change to make this list work? For JDO 1
applications that test their implementation, we will need to include a
requirement that any collection/map type that can be tested for from JDO1 be
represented in the list. For JDO 2 TCK, we can require that they are
supported.

 

How about a line in the spec, e.g.

 

For JDO 2, this feature is not optional. For compatibility with applications
written to the JDO 1 interface, this feature must be included in the
optional features list.

 

Add this line for each of the options:

 

javax.jdo.option.ArrayList

javax.jdo.option.LinkedList

javax.jdo.option.TreeMap

javax.jdo.option.TreeSet

javax.jdo.option.Vector

javax.jdo.option.List

Craig

 

On Feb 13, 2006, at 1:07 PM, David Jordan wrote:





As I have lobbied before.

Some of the optional collections are supported by all of the JDO
implementations (that I am aware of). A developer reaction back when JDO 1.0
was first released was that there were an insufficient number of collections
that were required and guaranteed to be available with all implementations.
A few of our optional collections may also be required (i.e. guaranteed)
with EJB 3.0. So I'd recommend that some of our optional collections be
required. Such an action would affect this list.

 

David Jordan

Object Identity, Inc.

 

-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
Sent: Monday, February 13, 2006 4:00 PM
To: JDO Expert Group; Apache JDO project
Subject: Negative VOTE Issue 138: Define optional features for PMF

 

Javadogs,

 

Here's the proposed optional feature list for JDO 2. Please make sure your
favorite optional feature is accurately represented.

 

<proposed>

Optional Feature Support

Collection supportedOptions();

The JDO implementation might optionally support certain features, and will
report the features that are supported. The supported query languages are
included in the returned Collection.

A11.5-1 [This method returns a Collection of String, each String instance
representing an optional feature of the implementation or a supported query
language. The following are the values of the String for each optional
feature in the JDO specification:

javax.jdo.option.TransientTransactional

The JDO implementation supports the transient transactional life cycle
states.

javax.jdo.option.NontransactionalRead

The JDO implementation supports reading and querying outside a transaction.

javax.jdo.option.NontransactionalWrite

The JDO implementation supports the persistent-nontransactional-dirty life
cycle state.

javax.jdo.option.RetainValues

The JDO implementation supports retaining values of persistent instances
after commit.

javax.jdo.option.Optimistic

The JDO implementation supports the optimistic transaction semantics.

javax.jdo.option.ApplicationIdentity

The JDO implementation supports application identity for persistent classes.

javax.jdo.option.DatastoreIdentity

The JDO implementation supports datastore identity for persistent classes.

javax.jdo.option.NonDurableIdentity

The JDO implementation supports nondurable identity for persistent classes

javax.jdo.option.ArrayList

The JDO implementation supports persistent field types of ArrayList.

javax.jdo.option.LinkedList

The JDO implementation supports persistent field types of LinkedList.

javax.jdo.option.TreeMap

The JDO implementation supports persistent field types of TreeMap.

javax.jdo.option.TreeSet

The JDO implementation supports persistent field types of TreeSet.

javax.jdo.option.Vector

The JDO implementation supports persistent field types of Vector.

javax.jdo.option.List

The JDO implementation supports persistent field types of List. This is now
a requirement but the option is for compatibility with JDO 1.0 where this
support was optional.

javax.jdo.option.Array

The JDO implementation supports persistent field types of Array.

javax.jdo.option.NullCollection

The JDO implementation allows null collections to be stored. Most relational
implementations do not distinguish between empty and null collections, and
this option will not be set for those implementations.

javax.jdo.option.ChangeApplicationIdentity

The JDO implementation supports changing of the application identity of
instances.

javax.jdo.option.BinaryCompatibility

The JDO implementation supports the binary compatibility contract.

javax.jdo.option.GetDataStoreConnection

The JDO implementation supports use of a direct datastore connection.

javax.jdo.option.GetJDBCConnection

The JDO implementation supports use of a direct datastore connection that
implements the java.sql.Connection interface.

javax.jdo.query.SQL

The JDO implementation supports SQL for queries executed via the
javax.jdo.Query interface.

javax.jdo.option.UnconstrainedQueryVariables]

The JDO implementation supports JDOQL queries that contain a variable
without a contains clause to constrain the variable.

javax.jdo.option.version.DateTime

The JDO implementation supports use of a the date-time strategy for version
checking.

javax.jdo.option.version.StateImage

The JDO implementation supports use of the state-image strategy for version
checking.

javax.jdo.option.PreDirtyEvent

The JDO implementation supports event notifications of changes made to
persistent instances before the instance is made dirty.

javax.jdo.option.mapping.HeterogeneousObjectType

The JDO implementation supports mapping a persistent field of type Object to
multiple types. There is no standard way to map this support.

javax.jdo.option.mapping.HeterogeneousInterfaceType

The JDO implementation supports mapping a persistent field of a persistent
interface type to multiple types. There is no standard way to map this
support.

javax.jdo.option.mapping.JoinedTablePerClass

The JDO implementation supports mapping persistent class inheritance
hierarchies to tables in which each class, including abstract classes, is
mapped to a table; and each table mapped to a subclass defines a primary key
that has a foreign key relationship to the primary key of the table mapped
by the superclass.

javax.jdo.option.mapping.JoinedTablePerConcreteClass

The JDO implementation supports mapping persistent class inheritance
hierarchies to tables in which each concrete class (excluding abstract
classes) is mapped to a table; and each table mapped to a subclass defines a
primary key that has a foreign key relationship to the primary key of the
table mapped by the superclass.

javax.jdo.option.mapping.NonJoinedTablePerConcreteClass

The JDO implementation supports mapping persistent class inheritance
hierarchies to tables in which each concrete class (excluding abstract
classes) is mapped to a table; and there is not necessarily any foreign key
relationship among the mapped tables.

javax.jdo.option.mapping.RelationSubclassTable

The JDO implementation supports mapping persistent fields containing
relationships to classes in an inheritance relationship that use
subclass-table as the field mapping strategy.

A11.5-2 [The standard JDO query must be returned as the String:

javax.jdo.query.JDOQL]

Other query languages are represented by a String not defined in this
specification.

</proposed>

 

Craig Russell

Architect, Sun Java Enterprise System  <http://java.sun.com/products/jdo>
http://java.sun.com/products/jdo

408 276-5638  <mailto:Craig.Russell@sun.com> mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!

 





 

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!

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message