Vladimir is correct but I am working hard to display Enumerable convention’s status as “built-in”.
The data has to come out of Mongo and into JDBC somehow, so the plan needs to bridge into a calling convention that Calcite understands. Until recently Enumerable has been the calling convention of choice. It involves translating the tree of RelNodes into java source code that implement the Enumerable interface (similar to Iterable). In the case of Mongo this was a thin layer — execute a Mongo query using DBCollection.aggregate, and convert to an Enumerable — but it had to exist because Enumerable was the only convention. Now we have Interpreter and interfaces such as ScannableTable a better way, especially for gateways that are not performance-critical, would be to just return an interpretable RelNode. That will take a little work (we need to make the translation to interpreter nodes a bit more extensible) but not much. Trevor, can you share what you are working on? I could work with you to get it into interpreter convention, if you like. Also, the comment thread on https://issues.apache.org/jira/browse/CALCITE-506 covers similar territory: “I'd love people to be able to write adapters without getting their hands dirty with the enumerable convention”. You might find EnumerableRelImplementor.stash solves the problem of passing project lists without generating complex code. Julian On Dec 12, 2014, at 11:39 AM, Vladimir Sitnikov <[email protected]> wrote: > Hi, > > You are looking into Mongo-to-enumerable converter. > > Calcite has 'built-in' execution engine that is called 'enumerable > convention'. > It can execute almost all kinds of relational expressions. > Typically it operates via 'Enumerable' methods. > To glue this up, a java code is generated on the fly that arranges > enumerable calls in proper order. > > 'linq4j' is translated to this java code. So, technically, Calcite walks > this linq4j when preparing java code for enumerable execution. > > Mongo-to-enumerable is needed when you push just a subset of operations to > mongo and use the result as input to 'enumerable executor'. > Typically those kind of converters are not expected to include hardcore > linq4j stuff. > > Does it make sense? > > Can you share the sample of your code that makes you feel bad? > > Regards, > Vladimir Sitnikov
