openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: Custom StoreManager
Date Tue, 01 Apr 2008 15:33:51 GMT
There's definitely a convenience benefit to having an existing
hierarchy. However, even if there were an existing AST, wouldn't you
still need to write code to act on the tree? One of the advantages of
the ExpressionFactory-based approach is that you can hook directly
into the initial query parse, which I believe can be more efficient
than parsing to an AST and then walking that AST.

One thing to bear in mind when implementing an ExpressionFactory is
that the generated object graph can be cached in the
QueryCompilationCache (and is by default), so you should take care to
not store EM-related (i.e., Brokers, StoreManagers, StateManagers,
etc.) or mutable state in the instances.

-Patrick

On Tue, Apr 1, 2008 at 1:44 AM, xaviarias <xavihendrix@gmail.com> wrote:
>
>
>  Thanks, definetely I'll implement my own ExpressionFactory based on the
>  in-memory implementation. I wanted to avoid copy-paste the existing code,
>  but I guess it's too specific to be fully reused.
>
>  It could be interesting to uniform the expression hierarchy for general
>  purposes, if it is possible. I also saw conversations about subclassing JDBC
>  StoreManager for a particular rdbms, which is not the underlying idea I
>  think, but for the moment could be convenient.
>
>
>
>
>  Patrick Linskey-2 wrote:
>  >
>  > Hi,
>  >
>  > Generally, no -- those classes were created to implement the in-memory
>  > parser, not to be a general-purpose AST.
>  >
>  > That said, I think it would certainly be reasonable to extend their
>  > role to help meet yours. I think that it would take more than just
>  > making the classes public, though; there might be classes for which an
>  > instanceof check is not sufficient, and for which more methods would
>  > need to be exposed.
>  >
>  > I believe that it's possible for you to create your own AST (i.e.,
>  > your own ExpressionFactory that builds your own instances) and still
>  > take advantage of in-mem query processing when a particular query
>  > cannot be executed against the data store directly.
>  >
>  > -Patrick
>  >
>  > On Mon, Mar 31, 2008 at 2:40 AM, xavihendrix <xavihendrix@gmail.com>
>  > wrote:
>  >>
>  >>  Hello, I am implementing a custom StoreManager to access relational data
>  >>  through a propietary product API, wich my company has bought but don't
>  >> want
>  >>  to use in all data accesses. The JPA has to be the uniform persistence
>  >> layer
>  >>  for all units, which can be configured to use a particular StoreManager
>  >>  (JDBC, propietary API, etc.)
>  >>
>  >>  So, at the moment of executing internally the query in my StoreQuery and
>  >>  construct the delegate object (of the propietary API), I walk through
>  >> the
>  >>  expressions provided by InMemoryExpressionFactory with an
>  >> ExpressionVisitor
>  >>  (I use this factory because in-memory post-processing can be required
>  >> due to
>  >>  limitations on the propitary API).
>  >>
>  >>  The problem is that all expressions have a protected visibility, so I
>  >> cannot
>  >>  know wich expression I am processing and cannot construct my delegate
>  >> query.
>  >>  Is there a way to obtain the type of expression of a
>  >>  org.apache.openjpa.kernel.exps.Expression? A kind of JavaTypes for
>  >>  expressions that tells you if it is and AND, OR... ?
>  >>
>  >>  It's a bit weird, I hope someone has been found the same problem.
>  >> Thanks!
>  >>
>  >>  --
>  >>  View this message in context:
>  >> http://www.nabble.com/Custom-StoreManager-tp16394955p16394955.html
>  >>  Sent from the OpenJPA Users mailing list archive at Nabble.com.
>  >>
>  >>
>  >
>  >
>  >
>  > --
>  > Patrick Linskey
>  > 202 669 5907
>  >
>  >
>
>  --
>  View this message in context: http://www.nabble.com/Custom-StoreManager-tp16394955p16416900.html
>
>
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>



-- 
Patrick Linskey
202 669 5907

Mime
View raw message