chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Hübel <>
Subject Proposal for query integration in chemistry/opencmis
Date Wed, 26 May 2010 07:23:30 GMT
Hi all,


in the past weeks I had a closer look at the query part that Florent added a while ago. I
would like share a few thoughts how to evolve this with you.


My proposal is to integrate query in a two-level approach:


Level 1 is what we have today, the grammar, build scripts, tests and sample code. Integration
is done using ANTLR and extending the rules in the grammar files so that you can integrate
your custom logic in a tree walker. This gives you fine control about everything, there are
almost no dependencies to other parts of the code and allows full customizing including extending
the grammar. On the other side you need to be familiar with ANTLR, its concepts, design and
extension points.


Because ANTLR is not even a trivial tool I suggest to introduce in future a second level of
integration that takes away this burden and offers Java interfaces and support classes instead.
This is intended for simpler integrations that should be sufficient for many standard cases.
My current idea is to cover the SELECT and FROM parts in  common support classes and to provide
an interface (callback-like) for the WHERE part that can be implemented repository specific.
The common classes map to existing Java interfaces we already have for the type system. In
addition it might make sense to have some classes that assist in building a response (respecting
the select part). My current guess is that the typical case where you need to map CMISQL to
real SQL according to your internal relational data model can be handled using this simple
level of integration. For the full-text part this should be pretty similar.


This outline is rather high-level and abstract, so we need an example to justify if this works.
Therefore I will try to implement this for the InMemory server with a clear separation between
common and in-memory-server specific parts. If this has reached a certain level of maturity
( I don't intend to implement the full scope of query for in-memory server, e.g. JOINs, etc.)
we can review this and then decide if it makes sense to take the common parts out of the in-memory
sub-project and make them part of the server-support package. If we come to the conclusion
that this doesn't make sense we still would have a piece of sample code how to implement query.


Probably trivial but just to mention it: Of course you can just use the DiscoveryService interface
and implement everything on your own.  This might be the case if you want to use a different
parser generator for example or want to get rid of the ANTLR runtime library.




  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message