Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 18 Nov 2005 13:42:25 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: dtd property element
In-reply-to: <1132309656.437dac9821b68@webmail.jpox.org>
Sender: Craig.Russell@Sun.COM
To: Apache JDO project <jdo-dev@db.apache.org>,
        JDO Expert Group <jdo-experts-ext@Sun.COM>
Message-id: <12E893C8-1BFA-4727-A320-8EA9D1256466@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_JvwDBgbzHXnLkw/rJk6v9Q)"
References: <1131494313.43713ba9ac5c1@webmail.jpox.org>
 <B204EBD6-4F2A-4BD5-A6F4-840446926E28@sun.com>
 <1132309656.437dac9821b68@webmail.jpox.org>

--Boundary_(ID_JvwDBgbzHXnLkw/rJk6v9Q)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT

Hi Erik,

On Nov 18, 2005, at 2:27 AM, erik@jpox.org wrote:

> Thanks Craig.
>
> When the JDO implementation generates the classes at runtime...
>
> 1 - Should the field-name attribute be used to generate the field  
> in the class?

No. The intent of the persistent interface is that the JDO  
implementation creates an "anonymous" implementation class. There is  
no requirement to even create a persistence-capable class; it's  
perfectly fine to use dynamic Proxy as a strategy and to not even  
define fields with names.
>
> 2 - There is no attribute that defines the binary name of the  
> generated class at
> runtime. We may need a metadata attribute to allow specifying it,  
> and secondly,
> we should define a default naming for the generated class if not  
> specified in
> the metadata.
>
> I have two proposals for a default:
>
> - <interface-package>.Jdo<interface-classname>
> - <interface-package>.<interface-classname>Impl
>
See above. There is no value in having a persistence-capable concrete  
class visible to the user, as there is no user-visible behavior of  
such a class. The only thing that a user can and should rely on is  
that the persistent properties are available from the implementation  
instance.

It seems that I wasn't clear in my reply below. Probably because  
there are two different uses for persistent interfaces and properties.

The use referred to above is a persistent interface used in the  
context of PersistenceManager.newInstance(interface.class). In this  
case, the implementation generates some anonymous class that  
implements the interface and can be made persistent via the standard  
PersistenceManager API.

The use I thought you asking about below is where a user-defined  
persistence capable class is declared to implement a persistent  
interface, even without a persistent mapping for the persistent  
interface. In this case, user-defined persistence capable classes  
need a mapping between the persistent property name and the  
persistent field name. This allows queries that take the persistent  
interface as the candidate class and maps the queries to concrete  
classes with fields.

I could add some text to the spec if you think it would help.

Regards,

Craig
> Regards,
>
> Erik Bengtson
> Quoting Craig L Russell <Craig.Russell@Sun.COM>:
>
>> Hi Erik,
>>
>> On Nov 8, 2005, at 3:58 PM, erik@jpox.org wrote:
>>
>>>
>>> Hi,
>>>
>>> The element property in DTD misses the persistence-modifier  
>>> attribute.
>>>
>>> On the same suject, I don't know the purpose of field-name in
>>> property. Can
>>> someone give me a light?
>>
>> The purpose of field-name in property is to allow a query against a
>> property to be mapped to the appropriate field in each mapped
>> implementation class. So, if querying for a property called startDate
>> in Employee, it would be mapped to field beginDate in
>> PartTimeEmployee and to field beginningDate in FullTimeEmployee.
>>
>> Craig
>>
>>>
>>> Regards,
>>>
>>> Erik Bengtson
>>>
>>>
>>>
>>>
>>>
>>
>> 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!


--Boundary_(ID_JvwDBgbzHXnLkw/rJk6v9Q)--