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 Thu, 04 Dec 2008 21:30:44 GMT

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

Craig Russell commented on JDO-615:
-----------------------------------

> Re: priority of user-defined metadata. 
> Why not make user-defined metadata highest priority? That way the user has a way of overriding
some package.jdo in the CLASSPATH which they can treat as their fallback. 

The rationale for the algorithm used today is that once metadata has been defined, there may
be other metadata that depends on it (e.g. inheritance and relationships). So if you change
this you are in danger of breaking things that are working for other parts of the application.
I don't have a use-case for changing metadata that's already been defined. Do you?

> Other item : do we want to provide access to metadata for a class being used by the persistence
process ? I'd favour something simple like ClassMetadata pmf.getMetadata(String classname);

> This will allow applications to access mapping info (e.g table used for a class) and
utilise it in a different part of their app. Obviously it would be down to individual implementations
whether they support any subsequent changes to that metadata if handed out to the user.

There are two questions: do we support a way for an application to get the current definition
of metadata? I'd say yes.

Do we support changing metadata by modifying the metadata objects that are given to the application?
Without a clear understanding of the use-case for this (see above) I'd say no thanks. The
metadata instances should be immutable if given out, or at least give out a copy of what's
defined, that by definition doesn't change the current copy. Seems like it's "easy enough"
to copy metadata. 

Yet another more topic: security. We probably need to add a security bit to the registerMetadata
and getMetadata calls. We already have the getMetadata permission but might want a setMetadata
permission as well.

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


Mime
View raw message