Simon, It's not clear to me how this is a result of scripting language support:
"Another problem with it is that sooner or later you need your inner language (your SQL engine) to have access to your outer environment, for example, to find out if you have lots of filespace free." Could you please elaborate? The ability to declare FOREIGN KEYS and TRANSACTIONS are not what I had in mind when I used the phrase "scripting language". I am thinking of full-blown procedural logic integrated with the RDBMS. The foremost example that comes to mind is VBA in MS-Access, though many other examples are available, e.g. Revelation, Borland Paradox, or even java in Oracle. Now, comparing SQLite with those other databases is like comparing a giraffe with an alligator and then complaining that the alligator cannot reach the tall acacia fruits or that the giraffe cannot take down a water buffalo because he cannot fully submerge and his teeth are too dull. I am very aware of SQLite's many strengths and how it is different from those other databases. But I'd still like SQLite to have an integrated interpreted scripting language if that were possible, because I know from experience that if the interpreted scripting language integration is well handled you can end up with the best of both worlds: SQL set logic and procedural logic with arrays/collections. That is of course one of the main reasons for the loadable extensions module in SQLite. An important difference is that the scripting language can be "sandboxed" and prevented from referencing the file system. If support for an interprested scripting language were available, Google's and Adobe's and other similar implementations of SQLite could have access to the sort of power that loadable extensions offer. Regards Tim Romano On Sat, May 1, 2010 at 10:04 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 1 May 2010, at 2:25pm, Tim Romano wrote: > > > In part, this is a very broad question but I hope it's not unacceptable. > > From a birdseye perspective, what is involved in integrating an > interpreted > > scripting language with a database engine? I am aware that SQLite > supports > > loadable extensions, but would the SQLite architecture also permit the > > integration of an interpreted scripting language? An integrated > scripting > > language makes an already powerful database engine orders of magnitude > more > > useful especially when one is solving ad hoc data problems requiring very > > rapid turnaround. SQlite with, say, an ActionScript interpreter (ala > > MS-Access->VBA) would be an amazingly powerful desktop tool. Do you know > of > > any project pursuing such an integration? > > SQLite already contains three scripting elements. The first is TRIGGERs, > where you can supply a sequence of operations to be completed when certain > things happen. The second is FOREIGN KEY support, which is more restricted > in terms of what can be done, but easier to understand. And the third is > the COMMIT/ROLLBACK system which can also be considered a method of > pre-programming certain events. > > One problem with implementing scripting within a database language is that > it turns into just another layer of complication. If you migrate some of > your application logic into the scripting language it gives you another > layer of stuff to debug. I already don't know how a value arrived in one of > my fields: is it a default value for that column ? Or did it arrive there > via a TRIGGER ? Or was it explicitly put in there by my application ? If > you add another layer to that you're complicating an already complicated set > of possibilities. > > Another problem with it is that sooner or later you need your inner > language (your SQL engine) to have access to your outer environment, for > example, to find out if you have lots of filespace free. At that point you > have to start specifying things about your OS (for example, that it actually > does have a file system and you're not just using memory). Which means > you're going to restrict yourself to only some implementations of SQLite. > Which then means SQLite either has to have forks or waste code in > environments it's not suitable for. That way madness lies. > > So the conventional way to handle it is to put your SQL engine near the > bottom of the heap, just above the file system. If you want it to act as if > it has a scripting language, implement your own, and call SQLite only by > your own calls rather than directly. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
