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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> > 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.
