db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jordan" <david.jor...@objectidentity.com>
Subject RE: Company model for JDO 2.0 TCK
Date Mon, 18 Apr 2005 19:42:55 GMT

I know, just suggesting a way to reduce the workload.

David Jordan
Object Identity, Inc.


-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
Sent: Monday, April 18, 2005 3:37 PM
To: 'JDO Expert Group'
Cc: jdo-dev@db.apache.org; jdo-tck-ext@Sun.COM
Subject: Re: Company model for JDO 2.0 TCK

Hi David,

Good point. But this change does not change everything to use 
interfaces and abstract classes. Existing and new code that uses 
Company concrete classes will not change at all. In the metadata you 
continue to identify the concrete classes as persistent and everything 
else as non persistence capable.

The only thing that changes is the ability to define the abstract 
classes and interfaces as directly persistent so we can test this 
capability.

Craig

On Apr 18, 2005, at 11:25 AM, David Jordan wrote:

>
> Do you really need to make everything based on interfaces
> and abstract classes? It may make more sense to just do this
> for one part of the model, enough to test the functionality
> that needs to be tested.
>
> David Jordan
> Object Identity, Inc.
>
>
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM]
> Sent: Monday, April 18, 2005 2:16 PM
> To: JDO Expert Group; jdo-dev@db.apache.org; jdo-tck-ext@Sun.COM
> Subject: Company model for JDO 2.0 TCK
>
> Hi,
>
> Currently the Company model has concrete classes for the domain model.
> Since JDO 2.0 supports abstract classes and interfaces to directly
> model persistence, I'd like to propose refactoring the domain classes
> into three different parts per domain class, using Company as the
> example:
>
> ICompany: the interface that declares only the get/set properties
> ACompany: the abstract class that extends ICompany and declares and
> implements the equals, compareTo, deepCompareFields, and hashCode
> methods
> Company: the concrete class that extends ACompany. This class declares
> fields and implements the accessors of the class.
>
> This would allow existing code that uses Company to continue unchanged,
> as the Company contract is not changed. However, it would allow us to
> test the JDO 2.0 feature of persistent abstract classes and interfaces.
>
> The downside of making the change is that it triples the number of
> .java files and might be confusing.
>
> What do you all think?
>
> Craig
>
> 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!
>
>
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
View raw message