Re: [sqlite] Any plans to provide the sqlite3RunParser in the API

2012-08-14 Thread Bishwa Shrestha

On 08/13/2012 05:51 PM, Jay A. Kreibich wrote:

On Mon, Aug 13, 2012 at 03:43:46PM +0200, Bishwa Shrestha scratched on the wall:

Hi,

I've recently started using sqlite3 c-library. I'm using the
in-memory databases which are pretty fast since I'm loading data
dynamically into sqlite3 from a different backend (had to do this as
we wanted to provide an SQL interface to our users).

   If you want to provide an SQL interface to an existing data source, I
   would strongly recommend you look at Virtual Tables.  They look and
   smell like normal tables, but all of their access and data generation
   is done via application level code.  You can write a series of functions
   that essentially slip in between the SQL engine and the data access layer,
   and can redirect requests for table data to an external source.

   Virtual Tables can be read-write or read-only.  Read-only tables are
   pretty fast to implement, while read-write tables would allow
   external applications to modify the backend (no idea if that is
   desirable or not in your case).

   Virtual Tables are an extremely powerful and often overlooked part of
   SQLite.  You can do some pretty amazing and powerful things with them,
   as evident by the Full Text Search engine in SQLite, as well as the
   R-Trees extension, both of which are built on top of Virtual Tables.

   SQLite docs:
   http://www.sqlite.org/vtab.html
   http://www.sqlite.org/c3ref/create_module.html

   Virtual Tables are also covered fairly well in Using SQLite:
   http://shop.oreilly.com/product/9780596521196.do

-j

Hi Jay, thank you for your suggestion. I am looking at sqlite3 virtual 
tables and am liking what I see :) .


However, please note that this doesn't completely answer my original 
question. It would be nice if someone could respond in that regard.



 * Unknown - detected
 * English

 * English

javascript:void(0);
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Any plans to provide the sqlite3RunParser in the API

2012-08-14 Thread Dan Kennedy

On 08/14/2012 04:05 PM, Bishwa Shrestha wrote:

On 08/13/2012 05:51 PM, Jay A. Kreibich wrote:

On Mon, Aug 13, 2012 at 03:43:46PM +0200, Bishwa Shrestha scratched on
the wall:

Hi,

I've recently started using sqlite3 c-library. I'm using the
in-memory databases which are pretty fast since I'm loading data
dynamically into sqlite3 from a different backend (had to do this as
we wanted to provide an SQL interface to our users).

   If you want to provide an SQL interface to an existing data source, I
   would strongly recommend you look at Virtual Tables.  They look and
   smell like normal tables, but all of their access and data generation
   is done via application level code.  You can write a series of
functions
   that essentially slip in between the SQL engine and the data access
layer,
   and can redirect requests for table data to an external source.

   Virtual Tables can be read-write or read-only.  Read-only tables are
   pretty fast to implement, while read-write tables would allow
   external applications to modify the backend (no idea if that is
   desirable or not in your case).

   Virtual Tables are an extremely powerful and often overlooked part of
   SQLite.  You can do some pretty amazing and powerful things with them,
   as evident by the Full Text Search engine in SQLite, as well as the
   R-Trees extension, both of which are built on top of Virtual Tables.

   SQLite docs:
   http://www.sqlite.org/vtab.html
   http://www.sqlite.org/c3ref/create_module.html

   Virtual Tables are also covered fairly well in Using SQLite:
   http://shop.oreilly.com/product/9780596521196.do

-j


Hi Jay, thank you for your suggestion. I am looking at sqlite3 virtual
tables and am liking what I see :) .

However, please note that this doesn't completely answer my original
question. It would be nice if someone could respond in that regard.


There are no plans to make sqlite3RunParser() part of the
API.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] Any plans to provide the sqlite3RunParser in the API

2012-08-13 Thread Bishwa Shrestha

Hi,

I've recently started using sqlite3 c-library. I'm using the in-memory 
databases which are pretty fast since I'm loading data dynamically into 
sqlite3 from a different backend (had to do this as we wanted to provide 
an SQL interface to our users).



It would be very nice if I could also use sqlite3RunParser to get the 
list of tables I need to load into in-memory databases. Currently, I'm 
loading all the tables, which is a performance hit.


Thanks in advance for suggestions / advices.

bishwa
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Any plans to provide the sqlite3RunParser in the API

2012-08-13 Thread Jay A. Kreibich
On Mon, Aug 13, 2012 at 03:43:46PM +0200, Bishwa Shrestha scratched on the wall:
 Hi,
 
 I've recently started using sqlite3 c-library. I'm using the
 in-memory databases which are pretty fast since I'm loading data
 dynamically into sqlite3 from a different backend (had to do this as
 we wanted to provide an SQL interface to our users).

  If you want to provide an SQL interface to an existing data source, I
  would strongly recommend you look at Virtual Tables.  They look and
  smell like normal tables, but all of their access and data generation
  is done via application level code.  You can write a series of functions
  that essentially slip in between the SQL engine and the data access layer,
  and can redirect requests for table data to an external source.

  Virtual Tables can be read-write or read-only.  Read-only tables are
  pretty fast to implement, while read-write tables would allow
  external applications to modify the backend (no idea if that is
  desirable or not in your case).

  Virtual Tables are an extremely powerful and often overlooked part of
  SQLite.  You can do some pretty amazing and powerful things with them,
  as evident by the Full Text Search engine in SQLite, as well as the
  R-Trees extension, both of which are built on top of Virtual Tables.

  SQLite docs:
  http://www.sqlite.org/vtab.html
  http://www.sqlite.org/c3ref/create_module.html

  Virtual Tables are also covered fairly well in Using SQLite:
  http://shop.oreilly.com/product/9780596521196.do

   -j

-- 
Jay A. Kreibich  J A Y  @  K R E I B I.C H 

Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable. -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users