Interesting.... the enum could also be the problem. What happens if
you create a new constructor that doesn't have the enum param, and run
the same query without the enum  data?

Can you describe what data you're trying to exclude from the query? I
understand your desire to avoid tying yourself to a particular
vendor's extensions, but in my opinion the benefits of living within
the regular JPA world from a lifecycle standpoint outweigh the costs
of living outside the JPA world for the query optimizations.

Note that from an API standpoint, you can use FetchPlans either via
query hints (i.e., without importing OpenJPA classes) or via
OpenJPA-specific APIs. This also means that you can externalize the
hints into named query definitions as well.

-Patrick

On 7/24/07, Prashant Bhat <[EMAIL PROTECTED]> wrote:
Hi,

Yes, the com.sample.entity.Account is an enhanced entity(and AccountType is
an enum).  And signature for the constructor is:
public Account(long id, String accountNumber, String name, AccountType
accountType, BigDecimal currentBalance);

Yes, I'm doing it for optimization and we had considered using FetchPlan but
as it is specific to OpenJPA, we choose this. Could you please suggest the
best approach for this type of scenario.

Thanks,
Prashant

On 7/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Is com.sample.entity.Account the entity type? I cannot recall if the
> spec allows selecting new into the enhanced instance type, but it
> certainly is not the intention, so that could be causing the problem.
>
> Generally-speaking, if you find that you're doing a SELECT NEW into an
> entity type, it probably means that you're fighting with OpenJPA --
> SELECT NEW is generally meant for projection and aggregate data, not
> as a means to obtain entity types. If you're doing so to achieve a
> tuning optimization, you might want to consider OpenJPA's fetch plan
> capabilities. Alternately, if you're just looking to load instances
> from the database, you can simply change the query to 'SELECT x FROM
> Account AS x'.
>
> -Patrick
>



--
Patrick Linskey
202 669 5907

Reply via email to