chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Hübel <jhue...@opentext.com>
Subject RE: JOINs
Date Tue, 05 Oct 2010 07:06:44 GMT
Hi Florent,

taking a look at this I have the impression that the basic ideas are still the same so there
are no objections from my side in general. I am happy that someone tries to use this and open
for any kind of improvement... A couple of more detailed questions and comments following
...

1)
You did a lot of reformatting and changes with line-end conventions. Is there something we
could improve in our code formatting templates or other Eclipse settings? 

2)
Comparing PredicateWalker with QueryConditionProcessor you have introduced a boolean return
value on each method. I don't get what's the meaning of this. In your implementation it seems
that you always return false. Could you explain a bit what your idea is here? My idea behind
this interface was that many implementations will try to translate CMISQL to SQL. So an implementation
typically will have a member variable for the target SQL query string and compose this while
walking the tree. I did not find a good way to do this as return values of the individual
node visitor methods and so just left them void.

3) 
Recently I have added additional pre- and post- methods in the interface for AND, OR, NOT.
The reason was that you typically have to set parentheses in your generated SQL call for the
contained expressions. So my idea was that if you have a ... WHERE ... A AND B in the cmis
query you have a preAnd method appending '(' to your generated SQL then process A then have
onAnd where you add " AND "  call, then process B and then have a postAnd method where you
append the ')'. I don't see this any longer in your code. What's the new approach dealing
with this?

4)
If we shift to the new interface/implementation you also should update the documentation:
http://incubator.apache.org/chemistry/queryintegration.html


Unfortunately the InMemory server is not the best example for an implementation. Usually a
repository will translate the query to some form of database query. The InMemory implementation
however is somewhat special in that implements the query engine on its own (and given that
of course very limited). If we could come up with a good example for translation into an SQL
query or something similar this would be very helpful.

Jens


-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com] 
Sent: Mittwoch, 29. September 2010 01:09
To: chemistry-dev@incubator.apache.org
Subject: Re: JOINs

It doesn't change the grammar at all, it's an alternate way of doing
what the AbstractQueryConditionProcessor does to allow dealing with
the WHERE clause. I made InMemoryQueryProcessor use it as it's
cleaner, but I didn't want to remove AbstractQueryConditionProcessor
yet until I know if people depend on it or what people think is best.

I'll let you take the time to look at this. FYI the base class is
https://svn.apache.org/repos/asf/incubator/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-support/src/main/java/org/apache/chemistry/opencmis/server/support/query/AbstractClauseWalker.java

Florent

On Tue, Sep 28, 2010 at 10:47 PM, Jens Hübel <jhuebel@opentext.com> wrote:
> I am currently on travel and don't have a chance to look at this for the moment. If this
is a replacement for the existing walker we should have a discussion on the list which way
to proceed (we shouldn't support two in the long run). Anyway great to see progress in this
area... I will followup once I had a chance to take a look at this.
>
> Jens
>
>
> -----Original Message-----
> From: Florent Guillaume [mailto:fg@nuxeo.com]
> Sent: Dienstag, 28. September 2010 19:31
> To: chemistry-dev@incubator.apache.org
> Subject: Re: JOINs
>
> I haven't done the JOIN part yet, but I added a new ClauseWalker
> interface (now used in InMemoryQueryProcessor). It should be simpler
> to use and extend.
>
> Florent
>
> On Mon, Sep 27, 2010 at 1:32 PM, Jens Hübel <jhuebel@opentext.com> wrote:
>> Hi Florent,
>>
>> the support for JOINS is currently weak. I don't think that anybody has used them
so far. Feel free to modify them.  Probably we also could implement a predefined walker object
at some point so that for a simple use case a user does not have to know about the tree structure.
>>
>> Jens
>>
>>
>> -----Original Message-----
>> From: Florent Guillaume [mailto:fg@nuxeo.com]
>> Sent: Montag, 27. September 2010 13:04
>> To: List-Chemistry
>> Subject: JOINs
>>
>> Hi,
>>
>> Is anyone using the structures related to JOINs in QueryObject? I
>> think I'll have to modify them a bit to be able to properly implement
>> JOIN-based queries in Nuxeo.
>>
>> Florent
>>
>> --
>> Florent Guillaume, Director of R&D, Nuxeo
>> Open Source, Java EE based, Enterprise Content Management (ECM)
>> http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87
>>
>
>
>
> --
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87
>



-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

Mime
View raw message