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. Jens
