openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: unenhanced class support
Date Thu, 26 Jul 2007 01:00:28 GMT
Patrick-

It looks very good to me! A few notes/questions on the patch:

1. One of the big TODOs seems to be support for compound primary keys  
(e.g., implementing  
ReflectingPersistenceCapable.pcCopyKeyFieldsToObjectId()).

2. Should ImplHelper._unenhancedInstanceMap be some sort of  
IdentityMap? If the user overrides MyEntity.equals() to return true  
if, say, their names are the same, we could get into trouble by doing  
just a simple map lookup.

3. It's pretty nice that we only need 54 invocations of  
ImplHelper.toPersistenceCapable().

4. InstrumentationFactory is scary with all the implementation  
dependent assumptions it makes, and the creation of temporary files  
and whatnot. If anyone knows of any way to cheat and obtain an  
InstrumentationFactory without having to create a jar file with the  
appropriately-formatted manifest, it'd be great.

5. I don't completely understand what is happening with the  
subclassing and enhancement. When we are redefining the classes, do  
we change the methods internally to do something like change String  
getName() { return name; } to String getName()  
{ ((MyGeneratedSubclass) this).pcProvideField(nameFieldIndex); }? I  
don't see any issue with doing this, but if it does turn out to be a  
problem, we could alternately have some lookup that does String  
getName() { ImplHelper.getPCProxyFor(this).pcProvideField 
(nameFieldIndex); }


Overall, it looks very good! I'm very excited to be able to start  
working towards eliminating the enhancement steps that people have  
found so cumbersome in the past.



On Jul 24, 2007, at 4:15 PM, Patrick Linskey wrote:

> Hi,
>
> I attached my current patch to OPENJPA-293. There are a number of open
> issues in the patch marked by '#####' marks -- I'd appreciate another
> set of eyes on those items in particular, and on the patch in general.
>
> Aside from that, I'm planning to run the CTS without enhancement on at
> some point in the next day or so, and want to get these changes
> committed soon, so that we can start figuring out whether or not it
> works.
>
> -Patrick
>
> On 7/22/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>> Hi Patrick,
>>
>> On Jul 22, 2007, at 12:51 PM, Patrick Linskey wrote:
>>
>> >> I think that no other implementation will have much of a better
>> >> solution. So I don't see that we should try to exclude user  
>> options
>> >> or a possible solution just because it's a poor performer.
>> >
>> > What about eviction? My feeling is that wherever OpenJPA would
>> > normally clear state (eviction, certain state transitions), we  
>> should
>> > keep the state available instead when we can't intercept and  
>> reload on
>> > demand.
>>
>> Yes.
>>
>> Craig
>> >
>> > -Patrick
>> >
>> > On 7/21/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>> >>
>> >> On Jul 20, 2007, at 11:42 AM, Patrick Linskey wrote:
>> >>
>> >> > So, I'm looking for answers to the following questions in
>> >> particular:
>> >> >
>> >> > 1. what should we do about { Java 5, no javaagent, field  
>> access }?
>> >> > Should we support this configuration, including the  
>> corresponding
>> >> > extra overhead, or should we require either property access or a
>> >> > javaagent specified in these configurations?
>> >>
>> >> I think we should do EAGER fetching of fields just like the other
>> >> implementations have to do.
>> >> >
>> >> > 2. what should we do about { Java 5, no javaagent, property  
>> access,
>> >> > flushed | cleared instances }? There is a much lower impact to
>> >> doing
>> >> > the dirty tracking in these configurations, since the scope is
>> >> > narrower. However, we might also be able to just not allow  
>> flush or
>> >> > clear or multiple sequential transactions if the persistence
>> >> context
>> >> > has references to unenhanced, unredefined user-created  
>> instances.
>> >>
>> >> I think that no other implementation will have much of a better
>> >> solution. So I don't see that we should try to exclude user  
>> options
>> >> or a possible solution just because it's a poor performer.
>> >>
>> >> Craig
>> >>
>> >> Craig Russell
>> >> Architect, Sun Java Enterprise System http://java.sun.com/ 
>> products/
>> >> jdo
>> >> 408 276-5638 mailto:Craig.Russell@sun.com
>> >> P.S. A good JDO? O, Gasp!
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Patrick Linskey
>> > 202 669 5907
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>
>
> -- 
> Patrick Linskey
> 202 669 5907


Mime
View raw message