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
