db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Bouschen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-615) MetaData specification API
Date Sun, 07 Dec 2008 18:25:44 GMT

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

Michael Bouschen commented on JDO-615:

Sorry for being late in this discussion.

The patch jdometadata5.patch looks good. However, I have a couple of remarks and most of them
have been discussed during the JDO TCK conference call Friday Dec 4:

- I like the idea that a Metadata component serves as factory method for its child components.
E.g. ClassMetada provides a method to add a new field or a method to add the inheritance metadata
for the class. The method has two tasks: create a new subcomponent instance and automatically
attach the new instance to the parent. Given that, I think we should skip method setParent
from the super interface Metadata.

- In the current patch the naming pattern for single valued subcomponent is "Subcomponent
setSubcomponent()" for the factory method and "Subcomponent getSubcomponent()" for the getter.
I find this confusing, because this looks like a JavaBeans pattern where the setter method
uses a very unusual signature. I propose to use "Subcomponent newSubcomponent()" for the factory
methods for both single-valued and multi-valued subcomponents.

- The factory method newSubcomponent may be called multiple times in the case of multi-valued
subcomponents, each call creates a new subcomponent. In the case of a single-valued subcomponent,
the first call creates the subcomponent and further call should throw an exception.

- I propose to have two overloaded factory methods: one version taking no arguments and another
version taking the required attributes of the subcomponent as parameters. E.g. ClassMetadata
would have the methods:
   FieldMetadata newField();
   FieldMetadata newField(String name);
The version w/o parameters allows a tool to create the subcomponent before processing all
the attributes of the subcomponent.

- As already included in the patch, I do not see the need for methods modifying the structure
of the metadata graph after it is setup, so we do not need any unset or remove methods.

- The methods for metadata attributes (that are not subcomponents) follow the JavaBeans pattern,
  void setColumn(String col);
  String getColumn();

- Boolean attributes use the Java Wrapper class Boolean as the return type. This allows to
return null in order to express, that the attribute has not been set. Should the corresponding
setter take a Boolean argument instead of a boolean? This way getter and setter use the same
type for the property.

> 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-5.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