On 14/03/2012 11:59 AM, Steve Ebersole wrote:
> To me its not about appeasing crowds. Its about removing barriers to
> popular development models. Whether you agree with it or not,
> interface driven development is a popular development model even in
> the domain model.
Sure, interface driven development is popular in general, but I've not
seen that doing so with entities is. That's just my experience.
> I am not sure what the end result of such discussions are supposed to
> be in terms of a proposal making it into the spec or not. But this is
> starting to feel like its going in circles. If this is something the
> rest of the group feels should not be in JPA thats fine.
The end results come after the discussion happens, and the discussion is
necessary to get as much information about the feature as possible.
Let's let all of the opinions get expressed and the value of the
proposal get assessed. This spec stuff takes time for a reason :-)
> I can easily do this in Hibernate. But thats yet another provider
> portability concern.
Are you saying this would be the only feature that Hibernate does beyond
the spec? ;-)
> On Wed 14 Mar 2012 10:19:09 AM CDT, michael keith wrote:
>> FTR, if we think adding *better* support for using interfaces (we
>> already have some interface support, it just requires that the
>> concrete class be specified in the mapping metadata) is going to
>> satisfy the DDD crowd we are deluding ourselves. Their problems with
>> JPA go beyond that simple issue.
>>
>> On 12/03/2012 10: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
>>>>
>>>
>