Javier: On Tue, Oct 5, 2010 at 3:11 PM, Javier Guerra Giraldez <jav...@guerrag.com>wrote:
> On Tue, Oct 5, 2010 at 8:14 AM, Robert Calco > <bob.ca...@softcraft-solutions.com> wrote: > > Again, this would be optional to keep the core light/simple. :) > > +1 > > for me, an 'ideal' relational DB system would look like this: > > - a collection of 'drivers' with a common API, but _absolutely_ no SQL > tinkering. the user should be guaranteed that any SQL he writes will > arrive byte-identical to the SQL engine. this layer is mostly done > with LuaSQL. mostly missing are parameterized queries and BLOBs, > possibly because most past proposals favored one or another SQL > dialect, suggesting it to be emulated for other engines... which is a > no-no at this layer. > Yea, there is a good case to be made to keep anything that can differ between the engines out of this layer. The least common denominator that remains is very basic indeed. > > - a 'common SQL' layer, to iron out most syntax differences between > SQL dialects. this would for example make a lot easier to use > prepared statements and parameterized queries. unfortunately, there > are some capability differences that can't be 'fixed' at this layer. > for example, recursive queries aren't supported by some engines, and > shouldn't be 'emulated' for others. 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? > > - an ORM.... well, not exactly 'O', since i feel that the cleanest Lua > code isn't too object oriented. possibly a fluent API to create > pseudotables would feel better. there are lots of colors to paint > this particular bikeshed. > Since I (re)discovered functional programming in recent years I've come to think of these mappers as entity wrappers. The 'impedence mismatch' simply doesn't exist when you think of everything in terms of tuples, for example, yet in our minds we think in terms of entities. The obsession with object-orientation, I agree, is not a good thing. I'm much more into 'multi-paradigm' languages these days than languages which lock you into one computational model. I was pretty impressed with the way Erlang, for example, came with it's own database (ironically called mnesia) -- what is most impressive about it is that the query language is part of the built-in syntax of the language for list comprehensions, and consequently there is NO impedance mismatch whatsoever. In the .NET world I've dealt a lot with LINQ (language-integrated query) which many ORM's on top of ADO.NET support. It would be nice of Lua did something like this, and database queries were just a specialized kind of query over lists or something. A good set of low-level drivers would be essential for this, as well as for more plain-vanilla ORMs, and that's one of my ulterior motives for getting involved. - Bob > > -- > Javier > > _______________________________________________ > Kepler-Project mailing list > Kepler-Project@lists.luaforge.net > http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project > http://www.keplerproject.org/ > -- Bob Calco DBA Softcraft Solutions bob.ca...@softcraft-solutions.com
_______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
