On Tue, Oct 5, 2010 at 9:40 AM, Robert Calco
<[email protected]> wrote:
>> it's possible that this layer
>> would require LPEG to get a robust compiler. maybe it could also
>> present a different API without the compiler, to express
>
> Didn't quit follow the last part of this point... could you restate?
i was thinking while reediting, and this part came up incomplete, in
part because that's not a finished idea by any means.
my thoughts were roughly like this:
- a robust common SQL dialect might get to the point of being a full
frontent/backend compiler:
commonSQL -> intermediate representation -> specific SQL
- such a compiler would benefit a lot from using LPEG
- a higher level ORM / LuNQ / fluent / whatever, could in theory just
emit this 'common SQL' dialect; but that means that itwould inherit
the LPEG dependency. no big deal for most of us; but it would be nice
to avoid it.
- what if the higher level layer doesn't emit SQL, but the
intermediate representation? that might redraw the layer diagram:
- lowest level: no SQL alterations (what is currently LuaSQL)
- second level: the backend emitter, generates several SQL dialects
from some internal representation.
- at the third level, some ways to generate that internal representation:
- a 'common sql' compiler
- an ORM / fluent / whatever API
--
Javier
_______________________________________________
Kepler-Project mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
