Skip to main content

[jsr338-experts] Re: proposal : @Entity on interfaces

  • From: Steve Ebersole <steve.ebersole@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: proposal : @Entity on interfaces
  • Date: Mon, 12 Mar 2012 11:01:44 -0500

Sorry, most of the pertinent discussion actually happened on IRC, not the email list. Just for completeness:
http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2012/%23hibernate-dev.2012-01-26.log.html


On 03/12/2012 09:53 AM, Steve Ebersole wrote:
JPA is about mapping concrete classes to relational databases. I never
claimed otherwise. If that was the mis-assumption from suggesting
@Entity be allowed on interfaces, I apologize for not being more clear.

No, as Oliver points out, the proposal is more about aliasing. There is
a thread on the Hibernate developer list[1] that discuss this in detail.
Basically I think that trends in development prefer interface-driven
design. Whether you agree with that or not for a JPA model is not really
the discussion. The proposal is more about working with that more
seamlessly.

Personally I think this should be a straight-up re-aliasing;
one-for-one. That and another more esoteric reason is what led me to
propose @Entity on the interface itself, with a attribute pointing to
the class being physically mapped. But I also see the benefit in
Oliver's suggestion to having that "link" on the entity *class*. This is
a point we specifically discussed on that Hibernate developer
discussion. In retrospect, I think the approach Oliver mentions is
better approach. It allows the jar separation he mentions, plus other
benefits.

[1] http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007627.html

On 03/12/2012 07:08 AM, Oliver Gierke wrote:
+1 on Mike's statement here. My initial intention (and I think Steve's
as well) was what Mike explained in his other email: aliasing access
to a JPA entity through an interface for the purpose of being able to
separate code and e.g. have the interfaces in one JAR and the
implementation class in another one.

The key part of what was being proposed (at least how I interpreted the
feature, Steve can correct me if I misinterpreted) was the ability to
"alias" an entity class. This just means that one might be able register
an entity class in the providers entity list keyed not only by the
concrete entity class, but also an (or more than one?) interface, so
that when the provider encounters that interface it gets loaded/saved by
the provider as the concrete entity class.


No additional metadata, simply metadata aliasing. I think ideas like
this originate from the trend for developers to build rich domain
models, follow Domain Driven Design and don't treat domain classes as
pure data containers. Although one might argue this is not what the
JPA spec is about I think we should make sure we don't get in the way
when following this approach so that devs don't get into a "I can't do
this because JPA can't deal with it" situation from a class' design
perspective.

Looking at the extended proposal @Entity on an interface feels a bit
weird as well, at least given the current semantics in the spec. I
could imagine an @EntityAlias though with the following usage model:

%<----------------------------------
@EntityAlias
public interface Person {

}

@Entity
public class MyPerson implements Person {

}
%<----------------------------------

Not sure I favor this over explicitly listing the alias interfaces on
the @Entity (e.g. @Entity(typeAlias = { Person.class }) as with the
original proposal you could implement the interface with a second
class without creating the conflict of two implementation classes
using the interface as alias.

Mike Keith wrote:

Having said that, if we think that aliasing is one of those things that
could stop large companies from using JPA we might decide to close our
eyes, hold our noses and go ahead and add some kind of support.


Could you elaborate on that? I don't quite get why this feature should
stop companies from using JPA.

@Entity(alias=Employee.class)
public class EmployeeImpl implements Employee {
// mappings ...
}

Where does one draw the line? Would we assume that a single alias is
enough and that an entity would not be allowed to specify a Set? For
example, that we would not need to support something like:

@Entity(aliases={Employee.class, Worker.class}) ... or ...
@Entity(aliasInterfaces=true)
public class EmployeeImpl implements Employee, Worker {
// mappings ...
}

The latter doesn't seem to complicate things, does it? At least given
the assumption there has to be a single implementation class to be
selected to back the type alias, right?

Cheers,
Ollie



[jsr338-experts] Re: proposal : @Entity on interfaces

(continued)

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/09/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Bernd Müller 03/11/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/11/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Matthew Adams 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Werner Keil 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/14/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/14/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/14/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/14/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/14/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Pinaki Poddar 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/13/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Pinaki Poddar 03/14/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Matthew Adams 03/14/2012
 
 
Close
loading
Please Confirm
Close