From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q0TITGJC022761 for ; Sun, 29 Jan 2012 19:29:16 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoCAJ+OJU/RVdS2kGdsb2JhbABDrk8IIgEBAQEJCQ0HFAQhgXIBAQEEEgIsARsdAQMMBgULAzgiAREBBQEcBjWHY5tHCotqgm+DfD+IcQIFC4ggDggCAgQKAgEMBAMEATsDhB4DGgIBBoM/BJUajhU9hAA X-IronPort-AV: E=Sophos;i="4.71,588,1320620400"; d="scan'208";a="129299322" Received: from mail-wi0-f182.google.com ([209.85.212.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Jan 2012 19:29:11 +0100 Received: by wibhn14 with SMTP id hn14so4399368wib.27 for ; Sun, 29 Jan 2012 10:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gz/daZJGQxkpiZjbgE1JsNrfMsPSfkPdgKXNYci8U4g=; b=gLATojPppLQcDcKl5Md5EtkyGY33eiLBAYG3x8PRKVuYhawi/Ge4NmYY54++PEDzXn aEF20TZW3Utb/XldMF5cdBQEAGdB8/czo2h5UhUQQite/vrPs7aHnDnpsh7PqLoOR6fH AaP/574+VKclDkKgwicSXf+oWFvAf0hrqLq94= MIME-Version: 1.0 Received: by 10.180.109.101 with SMTP id hr5mr7101165wib.14.1327861750957; Sun, 29 Jan 2012 10:29:10 -0800 (PST) Received: by 10.216.51.207 with HTTP; Sun, 29 Jan 2012 10:29:10 -0800 (PST) In-Reply-To: <1327835747.19516.23.camel@samsung> References: <1327835747.19516.23.camel@samsung> Date: Sun, 29 Jan 2012 19:29:10 +0100 Message-ID: From: Diego Olivier Fernandez Pons To: Gerd Stolpmann Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] SQL engine in OCaml with client side cache Caml-list, [Gerd Stolpmann wrote] > I think this is not possible. SQL always needs access to the complete > table for executing queries (including the complete indexes). I am surprised by your comments. Many systems have two-layer data storage (massive but slow one, fast but limited one), and that doesn't affect their semantics. Consider a compiler (heap/ registers), an operating system (swap files, RAM) or even a typical SQL database that keeps tables in memory for fast access. This is the same but the hard drive is on the server side, the RAM on the client side and they communicate by Internet. I am not saying that implementing a generic cache / swapping system for an SQL database is easy. That's why I added that for this specific application I can easily compute a superset of the data the user will need. Lets take an example : say my database contains sales history data for a convenience store chain for all stores in France, all products for last 5 years. If my user is the Coca-Cola replenishment manager in Paris, he only needs sales of Coca-Cola products for the last 5 similar days for each store in Paris. Thereafter I can generate a query on the server that sends that superset of data to the client and let the SQL client engine work on that. I may have underestimated the amount of work to be done, because I thought this would be on the easier side. My idea was the following Server side - 3rd part SQL database - OCaml bindings - Web communication interface Client side - SQL parser written in OCaml + interpreter - control system to guess superset of data and request from server - Web communication interface - output to JavaScript widget toolkit I was expecting to find most of the pieces already done and only having to glue them. I was actually more afraid of the JavaScript part than the SQL one... You can even find SQL engines written in JavaScript out there, to run in a web browser like Jade http://jacwright.com/489/in-memory-javascript-database/ or JOrder (JSON) https://github.com/danstocker/jorder At the end that's nothing but arrays and for loops. Diego Olivier