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?

Regards,

Erik Bengtson

[ Post a follow-up to this message ]

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!

[ Post a follow-up to this message ]

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 cla
ss?

2 - There is no attribute that defines the binary name of the generated clas
s at
runtime. We may need a metadata attribute to allow specifying it, and second
ly,
we should define a default naming for the generated class if not specified i
n
the metadata.

I have two proposals for a default:

- <interface-package>.Jdo<interface-classname>
- <interface-package>.<interface-classname>Impl

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:
> 
>
> 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
> 
>
> 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!
>
>

[ Post a follow-up to this message ]

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>:
> 
>
>
>

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!

[ Post a follow-up to this message ]

See inline...
 
>
> 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. 

JPOX is using another strategy. It creates the PersistenceCapable at runtime
,
and that's the context for the question.
[vbcol=seagreen] 
> 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.
>

Yes you were. Sorry for not inputing the context

[ Post a follow-up to this message ]

Hi Erik,

On Nov 18, 2005, at 4:00 PM, erik@jpox.org wrote:

> See inline...
> 
>
> JPOX is using another strategy. It creates the PersistenceCapable
> at runtime,
> and that's the context for the question.

That's fine. You are free to call the fields anything you want, and
in fact there is no requirement that the user tell you the field name.

I was just pointing out that with an alternative strategy, the issue
would not even arise because there are no fields to name!

Hope this satisfies your needs.

Craig

> 
>
> Yes you were. Sorry for not inputing the context
>

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!

[ Post a follow-up to this message ]