db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-615) MetaData specification API
Date Tue, 02 Dec 2008 21:00:46 GMT

    [ https://issues.apache.org/jira/browse/JDO-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652505#action_12652505

Craig Russell commented on JDO-615:

Just some high level comments for right now.

In order to mirror the xml metadata, you would need to start with a top level metadata root,
corresponding to the jdo element. You could construct this from the JDOHelper, e.g. public
JDOMetadata newJDOMetadata();

Then, JDOMetadata would have methods newPackageMetadata(String name), newQueryMetadata(String
name), and newFetchPlanMetadata(String name).

PackageMetadata would then have methods newInterfaceMetadata, newClassMetadata, and newSequenceMetadata.

If you use method chaining instead of constructors, then you could change this example to
be more self-describing:

    ClassMetaData cmd = dmdf.newClassObject(pmd,"Client", IdentityType.DATASTORE.toString(),
            Boolean.TRUE.toString(), Boolean.TRUE.toString(), Boolean.FALSE.toString(),
            ClassPersistenceModifier.PERSISTENCE_CAPABLE.toString(), null, null, null, "CLIENT",


Using the newClassMetadata construction would enforce the rule that a class can be a member
of only one package, so you can neither forget to assign the class to a package nor add the
class to more than one package.

If you want to enforce setting the required metadata, the newXXX could do this, e.g. for sequence
metadata, the name and strategy are required:
packageMetadata.newSequence("SQ1244", SequenceStrategy.CONTIGUOUS);

But most metadata is optional with reasonable defaults. 

For boolean properties, you might use Boolean as parameters/return values instead. Java 5
will automatically convert the setXXX parameters for you, but the getXXX will return a tristate
value which is needed to distinguish between the user setting a value and not. A boolean return
type doesn't allow this.

Finally, note that in the javax.jdo.annotations package we already have enums for the metadata.
So there's no need to repeat them. The only awkward thing is that they would be referenced
from the metadata package. But repeating their definitions in multiple packages seems worse.

> MetaData specification API
> --------------------------
>                 Key: JDO-615
>                 URL: https://issues.apache.org/jira/browse/JDO-615
>             Project: JDO
>          Issue Type: New Feature
>            Reporter: Andy Jefferson
>             Fix For: JDO 2 maintenance release 3
>         Attachments: jdometadata-3.patch
> We can specify MetaData via XML or annotations. The only way missing is via an API. I
propose mirroring the XML structure with interfaces of the form
> public interface MetaData
> {
>     addExtension(String key, String value);
>     removeExtension(String key, String value);
>     ...
> }
> public interface FileMetaData
> {
>     addPackage(PackageMetaData pmd);
>     ...
> }
> public interface PackageMetaData
> {
>     addClass(ClassMetaData cmd)
>     ...
> }
> public interface ClassMetaData
> {
>     addField(FieldMetaData fmd)
>     ...
> }
> public interface FieldMetaData
> {
>     setInheritance(InheritanceMetaData inhmd)
>     ...
> }
> and so on.
> We would then require a method on the PMF to register the metadata.
> If there are no objections to such a feature I'll propose a patch to try to provide all
current JDO2 capabilities.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message