After some more thought on the subject I
am still somewhat up in the air as to how we should name the mapping and type
hierarchy. Here is a summary of some of the options we’ve come up
with:
PersistentAttribute has an *AttributeMapping
BasicMapping (implements ColumnHolder) Basic
EmbeddedMapping Embedded
IdMapping (implements ColumnHolder) Id
*InvalidMapping InvalidAttributeMapping
VersionMapping (implements ColumnHolder) Version
TransientMapping Transient
*RelationshipMapping RelationshipAttributeMapping
*SingleRelationshipMapping
SingleRelationshipAttributeMapping
ManyToOneMapping
ManyToOne
*NonOwningMapping
NonOwningAttributeMapping
OneToOneMapping
OneToOne
*NonOwningMapping
NonOwningAttributeMapping
*MultiRelationshipMapping
MultiRelationshipAttributeMapping
OneToManyMapping
OneToMany
ManyToManyMapping
ManyToMany
PersistentType has a *TypeMapping
*Entity EntityTypeMapping
*Embeddable EmbeddableTypeMapping
*MappedSuperclass MappedSuperclassTypeMapping
*NullTypeMapping NullTypeMapping
ColumnPersistentAttributeFlavor should
just be ColumnHolder since it is implemented by mappings that hold a
Column. ColumnMapping makes it sound like we are referrring to a mapping
with the Column annotation.
Changed Reference to Relationship because
the spec refers to them as relationships
* these are my own preferences. I
can’t seem to decide between BasicMapping/Basic, but I know I don’t
like the verbosity of BasicAttributeMapping. Some arguments for Basic
would be that annotation names would match the class names. That’s
also an argument against calling it Basic, it’s easier to type BasicM
into the Type chooser since there are several other classes called just
Basic. BasicMapping would work well in the UI since BasicMappingComposite
is clearer than BasicComposite which could be anything. I think Entity,
Embeddable, MappedSuperclass are already used as nouns and do not need the
TypeMapping on the end. I tried to find consistent naming in the spec to
help me decide between Basic/BasicMapping, but was unable to find a
pattern. I lean towards BasicMapping.
At the moment I am thinking of changing
things to match the * items and leaving Basic/Id etc as they are. Then we
can get a feel for whether we like that or whether we want to rename those to –mapping
or –attributeMapping.
Any objections or other thoughts?
Any one leaning one direction or the other?
From: dali-dev-bounces@xxxxxxxxxxx [mailto:dali-dev-bounces@xxxxxxxxxxx]
On Behalf Of Paul Fullbright
Sent: Thursday, February 23, 2006
11:04 AM
To: General
Dali EJB ORM developer discussion.
Subject: Re: FW: Re: [dali-dev]
class name changes
Brian Vosburgh wrote:
Hmmm - I guess I don't like the verbosity of
-AttributeMapping. But EmbeddableMapping and NullMapping sound misleading: It's
not and "embeddable" mapping, it's a mapping of an
"embeddable" type; and Null Mapping could apply to either an
attribute or a type....
So I'd prefer: Embedded, Embeddable,
NullAttributeMapping (or some other substitute starting with something other
than Null)
I think consistency is key. My suggestion:
use the annotation name unless we're talking about an interface that doesn't
strictly have an annotation. (Id, Basic, ColumnAttributeMapping)
It's always difficult to invoke
"consistency" as a rationale, because what you're being consistent
with is arbitrary. I could likewise plead that class names should be nouns, for
"consistency's" sake. Most of these objects look, act, and smell like
Mappings (i.e. they associate an attribute with a database field etc.), so I
think they should be called Mappings.
Everything is arbitrary at some level. But I
think that there should be some level of consistency with our naming.
We're just debating what that level of consistency is.
Comments:
It's not so much that "Persistent" modifies
"AttributeMapping". Rather, "PersistentAttribute"
modifies "Mapping". (This object maps a persistent
attribute.) But I agree that AttributeMapping encapsulates the same
understanding.
As far as interface names and EMF, I'm planning to
provide a second layer of interfaces on top of a group of EMF interfaces simply
so I can hide all the crap that EMF generates from outside the plugin. I
want users to access the interfaces, but I don't want them to create instances
or modify them, which EMF exposes.
What should the naming convention be as an alternative to: FooImpl->Foo->IFoo?
The I naming convention, while perhaps discarded by many plugins, is pretty
rigorously followed by both the platform and jdt, both of which we are working
closely with. Just sayin'.
Ouch. Discard EMF? ... When were you planning on coding
these public-public interfaces and burdening us with yet another layer of
protocols to keep in synch? :-)
Not discard. Hide from the public. Work is
to be done at some future point.
- Paul