Looking at a couple of todo items in JpaCmpEngine

[Rick McGuire <ri...@gmail.com>]

While looking at some the executeSelectQuery() method in JpaCmpEngine, I 
noticed a couple of todo items that I think I'd be willing to tackle.  I 
do have a couple of questions about how things work just to make sure 
I'm understanding things properly.

The first todo is to wrap the result list in a wrapper List can can do a 
lazy activation of EntityBean result objects.  Am I correct in assuming 
that all of the objects in the list will be of the same type?  In other 
words, if the first result in the list is an EntityBean, then all of the 
results are EntityBeans and the list should be wrappered.  Conversely, 
if the first item is NOT an EntityBean, then can I assume that the 
result list can be immediately returned?

The second todo item states "don't activate beans already activated".  
How would one detect that situation to bypass the second activation?

Rick

Re: Looking at a couple of todo items in JpaCmpEngine

[Dain Sundstrom <da...@iq80.com>]

On Jun 13, 2008, at 10:52 AM, Rick McGuire wrote:

> While looking at some the executeSelectQuery() method in  
> JpaCmpEngine, I noticed a couple of todo items that I think I'd be  
> willing to tackle.  I do have a couple of questions about how things  
> work just to make sure I'm understanding things properly.
>
> The first todo is to wrap the result list in a wrapper List can can  
> do a lazy activation of EntityBean result objects.  Am I correct in  
> assuming that all of the objects in the list will be of the same  
> type?  In other words, if the first result in the list is an  
> EntityBean, then all of the results are EntityBeans and the list  
> should be wrappered.  Conversely, if the first item is NOT an  
> EntityBean, then can I assume that the result list can be  
> immediately returned?

With pure spec defined CMP, yes the collections are always the same  
type, but since we allow access to full JPA semantics that is not  
guaranteed.  In JPA you can have inheritance structures, so for  
example, you could query for all vehicles and get back a mixed  
collection of Cars and Motorcycles.  To make matters worse, we do want  
to support the mixing of CMP beans with pure JPA beans in the same  
model, which means Car could be a CMP bean and while Motorcycle just a  
JPA bean.

> The second todo item states "don't activate beans already  
> activated".  How would one detect that situation to bypass the  
> second activation?

I never figured out a way to do that.  One way I can think of is to  
maintain a list of all beans activated in the system and which PK they  
were assigned during activation.  Unfortunately, that would mean we  
would once again be double cache CMP engine.  The lac of cache in the  
JPA CMP engine makes it very simple and efficient, since the entire  
cache can be managed by the JPA implementation.

The only other possible implementation I can think of is to add an  
additional field to the generated subclass that contains the PK  
assigned during activation.  Then the engine could check if the new PK  
is different and reactivate.  This would make the generated class and  
the activation logic a bit more complex, but the real pain for me is  
it would make supporting direct CMPs where we don't generate a  
subclass at all.  This is not something we support right now, but  
something I'd like to support in the future.

I suggest you attack the streaming result sets first, ignoring the  
activation issue, since streaming should have the biggest performance  
improvement.

Oh ya, you may want to take a look at CmrSet as it contains logic to  
proxy and unproxy CMP beans.  Queries are bit more difficult as you  
have to support Remote interfaces in addition to Local interfaces, but  
I think the same basic logic applies.

-dain