Re 'integration tests', You'll need to double test set if you want to make sure interpreter returns proper values. Otherwise it might silently return wrong data.
I do not see how execution of integration tests in a separate module lowers the test coverage. On contrary, it makes clear if it is possible to create out-of-core executor. In the mean time I allmost got my EnumerableCorrelate working, so I hope you won't break much if you move things around. Regards, Vladimir Sitnikov 17 нояб. 2014 г. 8:27 пользователь "Julian Hyde" <[email protected]> написал: > Jacques, > > I appreciate the offer, and I'd like to do it. I'm tied up this week, but > free Mon and Tue next week, though. (Contact me back-channel and we can > schedule.) > > Moving org.apache.calcite.adapter.enumerable into its own module presents > some interesting challenges. > > 1. Quite a few other modules (e.g. mongo) depend on it. We could let them > continue to do that, or we could migrate them to the new ScannableTable SPI. > > 2. A lot of tests depend on enumerable, but they are not just tests of the > enumerable adapter; they are integration tests for the whole system. If we > move these into the enumerable adapter we lose a lot of coverage, and I > can't accept that. I think we should leave a basic query execution > capability in core, and implementations of the operators and a few > functions via the interpreter. > > These are not unrelated -- if a table implements ScannableTable then > Calcite will fire up an interpreter to read from it. > > Julian > > > > On Nov 15, 2014, at 3:05 PM, Jacques Nadeau <[email protected]> wrote: > > > > Hey Julian, > > > > I see you're working on the package reorganization /modularization. Want > > to meet up this week and we can pair tackle it for a day? I'm more than > > willing to drop by and lend a hand. > > > > Jacques > >
