DeveelDB is a complete SQL database system, primarly developed for .NET/Mono frameworks
tsutomi: I parsed your select statement (according to your grammar) - https://github.com/ArsenShnurkov/SqlParser-on-EtoParse/blob/9c4e2edadf0756760c6c40878c06441292af253a/test1/Globals.cs
not an easy job at all :)
the construction of the object model, though, it requires some better knowledge of the structure, also because here it's not constructing an AST model, rather provides a decision tree
I don't know Eto.Parse in depth and I don't really know yet its capabilities, neither how to use it
i.e. i don't understood is it possible to map the AST to your model, and how to do this
the *.Compile namespace includes a general contract to implement SQL compilers and it's a generic interface, that is invoked by the system to compile text into SQL Statement (implementations of IStatement interface in Deveel.Data.Sql.Statements)
instead the Deveel.Data.Sql.Parser is the default implementation of the SQL compiler based on Irony
Irony maps to ISqlNode instances, that are AST nodes
some of these nodes are SqlStatementNode, which are ISqlVisitableNode instances
the StatementBuilder class, that is an instance of ISqlNodeVisitor visits those statement AST nodes to reconstruct and instance of IStatement
the statements are those in Deveel.Data.Sql.Statements namespace, and are the commands to interact with the underlying platform
My goal is to first finish it at a level that is usable in a full cycle
Then I will think about document it
It's a job I'm not good at, and I can't even focus on it right now
many things are still undefined and the architecture change fast for many components
For instance, just today I changed the process for preparing and executing statements
this because solutions I had in mind didn't work
and you don't know in such context before you apply it. Other times, you simply think about a better solution on the way
so even if I'd take one month documenting, it risks to be obsolete in one week
That is also why I want first to reach a stable version
that is actually quite close
@ArsenShnurkov : I edited one of the pages you created in the DeveelDB Wiki... https://github.com/deveel/deveeldb/wiki/SQL-Execution-Plan
cannot go too much in details about the code specifics: it would be useless
it's best to express general principles
may be they are parts of schemata...
while constraints are not designed to be objects (and this could be a discussion point), rather parts of tables definitions, the indexes are intentionally been taken off: in fact, introducing indexes means radically modify the query optimization process, to verify columns in indexes, and fork the selector to the index. Also, the current design of the system gets only one kind of index: I've made modifications to the design to allow external index types (eg. Full-text backed by Lucene), but they're not supported yet
one of the features in version 2.5 will be the custom indexes
I generated docs with doxygen - https://arsenshnurkov.github.io/deveeldb-processed-by-doxygen/html/classDeveel_1_1Data_1_1Query.htm
but I am not happy with the result
because it's way of linking to source code is not attached to github