Makes sense to me! Seems about as good as it can get given the nature of our grammar tool. +1. I like the overall list of extension points BTW!
On Jul 16, 2016 5:24 AM, "abdullah alamoudi" <[email protected]> wrote: A small amendment to the description above: 1. Imports will be combined from the multiple files 2. List of additional statements will be combined with existing SingleStatement non-terminal. Cheers, Abdullah. On Sat, Jul 16, 2016 at 4:10 PM, abdullah alamoudi <[email protected]> wrote: > Hi everyone, > Recently, we are focusing more and more on building extension points into > the core of asterixdb. The goal of this is to enable rapid research > development and stable and robust core. We identified a few points of > extension that needs to be supported as follows: > > 1. CC/NC User Defined Components > 2. Metadata extension's datasets and extensible metadata entities > 3. Compiler Rules A mechanism to plug in a set of compiler rewrite rules > that can be run during plan generation. > > 4. Runtime Operators, Connectors, and Partitioners > > 5. Job Modification: An extension should be given a chance to inspect and > modify Hyracks jobs before they are executed. > > 6. Active Jobs {Start, Stop, Communication} > > 7. Language Parser's* Extensible Grammar*. > > 8. Query Translator must allow supporting additional types of statements. > > The trickiest of those is IMO the extensible grammar and in here, I am > proposing a mechanism in which an extension can build on core asterixdb's > grammar. > The mechanism will simply be a pre-processor for jj files before > generating java classes using javacc. Here is how it works. > > 1. Terminals in the original base jj file are final 2. Non-terminals can > be overridden by the extension file 3. The extension file can add more > terminals 4. A pre-processor will generate the final jj file before using > javacc to generate the java classes. > > > Comments? Thoughts? Disagreements? Suggestions? (Likes?) > > >
