Apache JDO Project - JDO2 annotations : split between JDO and ORM

Author

JDO2 annotations : split between JDO and ORM

Andy Jefferson

2006-10-15, 7:11 am

An initial split of JDO and ORM annotations is at :-

JDO :-
http://jpox.cvs.sourceforge.net/jpo...ox/annotations/

ORM:-
http://jpox.cvs.sourceforge.net/jpo...nnotations/orm/

Still to do :
@DatastoreIdentity currently has columns, indexed, etc. This will need
splitting off into its own class-level annotation (@DatastoreIdentityColumns)

@Version currently has columns, indexed etc. This will need splitting off into
its own class-level annotation (@VersionColumns)

@PersistenceCapable has joins. This can be replaced by the @Joins annotation.

@Field has table, unique, columns, delete-action, indexed. These will need
replacing by things like @JoinTable, @SecondaryTable, @Columns

Also some possibilities in the DTD/XSD are not currently specifiable using
annotations (e.g extensions on all main elements). We should aim to have an
equivalent specification in annotations that we can do in metadata (though
noting IIRC that JPA does not abide fully by this with some things being
specifiable in metadata that annotations aren't flexible enough for).

I'd be interested to see any proposed split that others have come up with.

PS. Is it so essential to split off the "mappedBy" attribute of <field> into
ORM ? It exists to define both ends of a bidirectional relation, and so would
be used by Managed Relationships irrespective of whether the datastore is
RDBMS (which is the principal target of such an "ORM" split).

--
Andy

Ilan Kirsh

2006-10-15, 1:11 pm

Hi Andy,

I agree that mappedBy should remain in Field. Same is true for indexed,
unique, deleteAction, sequence and valueStrategy, which can all be
useful also for object databases. I think that only table, column and
columns are specific for relational databases. Same is applied also for
Element, Key and Value, which were moved to orm.

I am not sure how a composite index should be declared using
annotations. Assuming that this is done using index and unique -
these two are also relevant to object databases.

Regards,

Ilan

----- Original Message -----
From: "Andy Jefferson" <andy@jpox.org>
To: "JDO Expert Group" <jdo-experts-ext@sun.com>; "Apache JDO project"
<jdo-dev@db.apache.org>
Sent: Sunday, October 15, 2006 1:39 PM
Subject: JDO2 annotations : split between JDO and ORM

> An initial split of JDO and ORM annotations is at :-
>
> JDO :-
> http://jpox.cvs.sourceforge.net/jpo...ox/annotations/
>
> ORM:-
> http://jpox.cvs.sourceforge.net/jpo...nnotations/orm/
>
>
> Still to do :
> @DatastoreIdentity currently has columns, indexed, etc. This will need
> splitting off into its own class-level annotation
> (@DatastoreIdentityColumns)
>
> @Version currently has columns, indexed etc. This will need splitting off
> into
> its own class-level annotation (@VersionColumns)
>
> @PersistenceCapable has joins. This can be replaced by the @Joins
> annotation.
>
> @Field has table, unique, columns, delete-action, indexed. These will need
> replacing by things like @JoinTable, @SecondaryTable, @Columns
>
>
> Also some possibilities in the DTD/XSD are not currently specifiable using
> annotations (e.g extensions on all main elements). We should aim to have
> an
> equivalent specification in annotations that we can do in metadata (though
> noting IIRC that JPA does not abide fully by this with some things being
> specifiable in metadata that annotations aren't flexible enough for).
>
>
> I'd be interested to see any proposed split that others have come up with.
>
>
> PS. Is it so essential to split off the "mappedBy" attribute of <field>
> into
> ORM ? It exists to define both ends of a bidirectional relation, and so
> would
> be used by Managed Relationships irrespective of whether the datastore is
> RDBMS (which is the principal target of such an "ORM" split).
>
> --
> Andy

Andy Jefferson

2006-10-15, 1:11 pm

Hi Ilan,

> I agree that mappedBy should remain in Field. Same is true for indexed,
> unique, deleteAction, sequence and valueStrategy, which can all be
> useful also for object databases. I think that only table, column and
> columns are specific for relational databases. Same is applied also for
> Element, Key and Value, which were moved to orm.

Thanks. I wasn't aware of whether you would use those concepts so just moved
everything :-)

> I am not sure how a composite index should be declared using
> annotations. Assuming that this is done using index and unique -
> these two are also relevant to object databases.

Presumably in MetaData you would do this ?
<class ...>
<index name="...">
<field name="a"/>
<field name="b"/>
</index>
</class>

so I would guess that we should allow something like
@Index (fields={"a", "b"})

i.e add a fields array element onto Index (same for Unique).
We also need to add an @Indices annotation to allow for multiple indices per
class - same for unique.

--
Andy

Ilan Kirsh

2006-10-15, 1:11 pm

> Hi Ilan,
>
>
> Thanks. I wasn't aware of whether you would use those concepts so just
> moved
> everything :-)

indexed and unique are certainly being used - also in Element, Key
and Value. I do not use deleteAction, sequence and valueStrategy
yet, but I think that it might make sense to use them in the future.

>
> Presumably in MetaData you would do this ?
> <class ...>
> <index name="...">
> <field name="a"/>
> <field name="b"/>
> </index>
> </class>

Yes, this way exactly.

> so I would guess that we should allow something like
> @Index (fields={"a", "b"})
>
> i.e add a fields array element onto Index (same for Unique).
> We also need to add an @Indices annotation to allow for multiple indices
> per
> class - same for unique.
>
> --
> Andy

That looks good except that personally I prefer @indexes over @indices.
I just found an interesting discussion about this issue, at:
http://fraserspeirs.livejournal.com/1000062.html
Maybe both can be supported but because this is your work, I assume you
have the privilege to choose your favorite form :-)

Regards,

Ilan

Andy Jefferson

2006-10-15, 1:11 pm

> indexed and unique are certainly being used - also in Element, Key
> and Value. I do not use deleteAction, sequence and valueStrategy
> yet, but I think that it might make sense to use them in the future.

OK.
The point that this raises is that my understanding of the "split" JDO-ORM was
to separate the ORM part out (by ORM I mean the part that can be specified in
the ORM metadata file) since it best practice to restrict schema-info to
MetaData (and not have it in annotations). So we would then have 2 sets of
annotations ... some as JDO and some as ORM. I didn't understand this as
separating out purely RDBMS-specific concepts that cant be used elsewhere. If
we go down that route, what do XML datastores use ? Or LDAP ?

e.g specifying an index name, is specifying something specific to the
datastore in use (which may not be usable in other datastores).

Comments ?

--
Andy

Ilan Kirsh

2006-10-15, 1:11 pm

>> indexed and unique are certainly being used - also in Element, Key
>
> OK.
> The point that this raises is that my understanding of the "split" JDO-ORM
> was
> to separate the ORM part out (by ORM I mean the part that can be specified
> in
> the ORM metadata file) since it best practice to restrict schema-info to
> MetaData (and not have it in annotations). So we would then have 2 sets of
> annotations ... some as JDO and some as ORM. I didn't understand this as
> separating out purely RDBMS-specific concepts that cant be used elsewhere.
> If
> we go down that route, what do XML datastores use ? Or LDAP ?
>
> e.g specifying an index name, is specifying something specific to the
> datastore in use (which may not be usable in other datastores).
>
> Comments ?
>
> --
> Andy

The question is whether this separation is really needed at all.
It might make sense to separate XML files but annotations,
when used, will be side by side ragardless of any separation.
In my opinion annotation separation is not really needed but
maybe I missed the point.

Ilan