openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From xaviarias <xavihend...@gmail.com>
Subject Re: Custom StoreManager
Date Wed, 02 Apr 2008 09:44:55 GMT

Yes I would need to write the code to act on the tree. The initial idea was
to build a tree from an custom expression factory which can decide wether to
create a propietary API expression or an in-memory expression. But I didn't
want to code all the expressions and that's why I switched to an expression
visitor. 

After an essay of coding it, I think is better to go back to first solution
and do something like:

class MyExpressionFactory extends InMemoryExpressionFactory {
... 
    public Expression and(Expression exp1, Expression exp2) {
         if (inMemory(AND, exp1, exp2)) {
               return super.and(exp1, exp2);
        }
        return new MyAndExpression(exp1, exp2);
    }
...
}

The problem now is to decide when an expression must be evaluated by the
propietary API or in-memory. Is it the AST builded bottom-up I guess? 

A good thing would be to execute a query in two phases: first, build one
partial AST query and execute against the propietary api (Val.eval(...)
methods could return API objects), and second filter the results with the
in-memory partial AST. Do you think it would be possible? There's a logical
problem here, maybe a transformation of the expression to its CNF or DNF
would be needed at AST build time?

Xavi


Patrick Linskey-2 wrote:
> 
> 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Custom-StoreManager-tp16394955p16446344.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Mime
View raw message