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-403) JDO2 Annotations
Date Tue, 03 Jul 2007 18:16:04 GMT

    [ https://issues.apache.org/jira/browse/JDO-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509966
] 

Craig Russell commented on JDO-403:
-----------------------------------

More specific comments on @Table, @SecondaryTable, @JoinTable...
> Why @JoinTable, @SecondaryTable, @Table ? 
> @Table is the equivalent of <class table="..."> 

It looks like it's more than that but less than the JPA @Table that also includes UniqueConstraints.
In JPA, catalog and schema don't specify the default catalog and schema of the mapping the
way JDO does.

> @JoinTable is the equivalent of <field table="..."> when the field is a container
field 

But then you still need the @Join annotation to specify the join column. Why isn't @Join sufficient?

> @SecondaryTable is the equivalent of <field table="..."> when the field is not
a container field 

In JPA, @SecondaryTable is used at the class level if there are multiple secondary tables
that can be used. It also specifies the join condition and uniqueness constraints. And it's
not clear how to specify the same table name but different catalog names. I don't think this
is a good model for JDO.

> They also map directly across to the same annotations in JPA. 

There are enough differences that I don't think JPA is a good model.

> They are not part of @PersistenceCapable, @Field since they are ORM and there was a time
when some other vendor requested that ORM annotations be kept separate from non-ORM. 

They are now in the same package and otherwise mixed. 

> @JoinTable, @SecondaryTable have schema/catalog whereas there is no such concept in the
XML since it is desirable to be able to specify the catalog/schema that ANY table is in, whether
it is primary or secondary or join. 

That's why we allow [[[database.]catalog.]schema.]table and reserve catalog and schema for
default settings for class and interface.

> Why not just have @Table at class and field level ? because it is clearer to have the
annotations named specific after what they are representing. 

At class level, we can just have table="TABLENAME". I agree we need to think a bit more about
field-level table mapping. I'm not completely happy with the xml for field-specific table
mapping. 

> We cant have an @Table element in @Join since then users would HAVE TO specify it (back
to limitations of default values in annotations). 

No, but you can have table="TABLE_NAME" in join. Which ties back to the xml pretty well. 


> JDO2 Annotations
> ----------------
>
>                 Key: JDO-403
>                 URL: https://issues.apache.org/jira/browse/JDO-403
>             Project: JDO
>          Issue Type: New Feature
>          Components: api2
>    Affects Versions: JDO 2 final
>            Reporter: Andy Jefferson
>            Assignee: Michelle Caisse
>             Fix For: JDO 2 maintenance release 1
>
>         Attachments: embedded.patch, fkpk.patch, jdo_2_1_annotations.jar
>
>
> It would be desirable for JDO2 to have its own set of annotations. We have developed
a set within JPOX that would likely serve as a starting point for such a set. In my opinion
they should be
> 1. Split into javax.jdo.annotations.jdo and javax.jdo.annotations.orm
> 2. Move ORM attributes from some of the JDO annotations and have a ORM annotation.

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