Sorry, but I do not at all like the overloading approach.
On 01/26/2012 07:39 AM, Eric Dalquist wrote:
> Perhaps an overloaded method for those that want generics and proxies?
>
> public<T> T load(Class<?> entityType, Class<T> proxyType, ...)
>
> It is kinda gross and results in higher level code knowing about the
> proxies but it would work for those people that are using proxyClass
> without having to make lower level changes.
>
> -Eric
>
> On 1/25/12 10:54 PM, Steve Ebersole wrote:
>> In terms of caching the resolution (User-UserImpl) on SessionFactory,
>> if we go that route, we can just limit it to specified proxyClass
>> values as opposed to a more free-form "any and all interfaces".
>>
>> Also, as far as the Session get and load methods, we don't have to
>> switch them to use generics. We can leave this feature for the load
>> access stuff.
>>
>> On Wed 25 Jan 2012 10:48:30 PM CST, Steve Ebersole wrote:
>>> Not really following what you are advocating Sanne.
>>>
>>> The problem with accepting the interface in the API is that we do not
>>> track this information today. From a Session, I have no way to get
>>> from User -> UserImpl unless I iterate every persister registered with
>>> the SessionFactory and check its mapped class type against the
>>> incoming interface. Yes we could start tracking such information but
>>> thats yet even more data cached as part of the SessionFactory.
>>>
>>> When you say that "the first case would work only in certain
>>> situations even with the current code, depending if you actually get a
>>> proxy or not", yes that is true but that is true specifically because
>>> at one point very early on this proxy class generation code was
>>> changed to not use the entity class as part of the proxy class
>>> definition when the mapping specified an interface as the proxy.
>>> Before that change it used to use entity class AND the proxy
>>> interface. What I am asking is whether we want to switch back to that
>>> to help facilitate generic signatures.
>>>
>>> In psuedo-code, the User/UserImpl example below today results in
>>> essentially this:
>>> public class ProxyClassForUserImpl extends Object implements User, ... {
>>> ...
>>> }
>>>
>>> It used to initially result in:
>>> public class ProxyClassForUserImpl extends UserImpl implements User,
>>> ... {
>>> ...
>>> }
>>>
>>> On 01/25/2012 05:00 PM, Sanne Grinovero wrote:
>>>> Would it be acceptable for such a use case to demand to use the
>>>> interface instead ?
>>>>
>>>> UserImpl u = (UserImpl) session.load( UserImpl.class, ... ) -> Illegal
>>>> type exception
>>>> User u = (User) session.load( User.class, ... ) -> Ok
>>>>
>>>> I think it would, as the first case would work only in certain
>>>> situations even with the current code, depending if you actually get a
>>>> proxy or not, so I would consider such code wrong even with the older
>>>> API.
>>>>
>>>> It would only break this currently working code:
>>>> User u = (User) session.load( UserImpl.class, ... )
>>>>
>>>> but it won't break at runtime, it would stop compiling.. which is a
>>>> good warning imho. Existing code (already compiled) would throw a
>>>> runtime exception though.
>>>>
>>>> -- Sanne
>>>>
>>>>
>>>> On 25 January 2012 21:26, Steve Ebersole<st...@hibernate.org> wrote:
>>>>> BTW, I did go back and verify that indeed the mismatch is with
>>>>> @Proxy.proxyClass specifying an interface. Consider an example:
>>>>>
>>>>> @Entity
>>>>> @Proxy(proxyClass=User.class)
>>>>> public class UserImpl implements User {
>>>>> ...
>>>>> }
>>>>>
>>>>> You will never be able to cast proxies instance of this thing to
>>>>> UserImpl. This call will fail with CCE:
>>>>>
>>>>> UserImpl u = (UserImpl) session.load( UserImpl.class, ... )
>>>>>
>>>>> get() may or may not work depending.
>>>>>
>>>>> This is the source of us not being able to offer generic signatures.
>>>>>
>>>>>
>>>>> On Wed 25 Jan 2012 01:33:14 PM CST, Steve Ebersole wrote:
>>>>>> In regards to the new "load access", a user asked why we don't
>>>>>> leverage generics.
>>>>>>
>>>>>> The problem is the existence of @Proxy#proxyClass. We have the same
>>>>>> issue with Session#load/get taking the entity Class. We can't use a
>>>>>> generic sig like:
>>>>>>
>>>>>> public<T> T load(Class<T> entityType, ...)
>>>>>>
>>>>>> because at times we return objects that are not typed to<T>. I have
>>>>>> to dive back into the specifics, but IIRC the problem is that we don't
>>>>>> do the expected thing and have the generated proxy class extend from
>>>>>> the entity class if @Proxy#proxyClass names an interface. I remember
>>>>>> this change way back when, but the specifics of why escape me at the
>>>>>> moment.
>>>>>>
>>>>>> IMO I think providing generic signatures would obviously be a great
>>>>>> improvement. Is it enough to change this behavior?
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>> --
>>>>> st...@hibernate.org
>>>>> http://hibernate.org
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
