I started working on an interface to the SQLite database engine (www.sqlite.org) today. The preliminary results are promising, but I'm now at the point where I should decide what direction to take the work. My initial thought is that this should be handled in the same manner as the other database interfaces. I'm not sure how well some of the interface design aspects will fit with the SQLite view of things, though. I was wondering if anyone can give me an idea of what I need to impliment in order to have it accessible through Sql.sql.
Bill
I think you would have to give more specific information about your problems. Taking Mysql as example you first have the Mysql module containing Mysql.mysql and Mysql.mysql_result. Then Sql.mysql inherits Mysql.mysql and acts as an interface adapter. Finally the Sql.Sql class creates an internal Sql.mysql object, given a mysql uri, on which it performs its operations.
An idea that I have had is to make things more statically compiled by letting Sql.get_db(string uri) return Sql.Mysql, which inherits Sql.DB (with the contents from Sql.sql) and Mysql.mysql.
/ Martin Nilsson (saturator)
Previous text:
2003-12-19 03:42: Subject: SQL
I started working on an interface to the SQLite database engine (www.sqlite.org) today. The preliminary results are promising, but I'm now at the point where I should decide what direction to take the work. My initial thought is that this should be handled in the same manner as the other database interfaces. I'm not sure how well some of the interface design aspects will fit with the SQLite view of things, though. I was wondering if anyone can give me an idea of what I need to impliment in order to have it accessible through Sql.sql.
Bill
/ Brevbäraren
Well, I don't know how much sense it will make to have a big_query() sort of functionality; as everything is done in-memory. Are those parts of the API needed to work with Sql.sql?
Bill
On Fri, 19 Dec 2003, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
I think you would have to give more specific information about your problems. Taking Mysql as example you first have the Mysql module containing Mysql.mysql and Mysql.mysql_result. Then Sql.mysql inherits Mysql.mysql and acts as an interface adapter. Finally the Sql.Sql class creates an internal Sql.mysql object, given a mysql uri, on which it performs its operations.
An idea that I have had is to make things more statically compiled by letting Sql.get_db(string uri) return Sql.Mysql, which inherits Sql.DB (with the contents from Sql.sql) and Mysql.mysql.
/ Martin Nilsson (saturator)
Previous text:
2003-12-19 03:42: Subject: SQL
I started working on an interface to the SQLite database engine (www.sqlite.org) today. The preliminary results are promising, but I'm now at the point where I should decide what direction to take the work. My initial thought is that this should be handled in the same manner as the other database interfaces. I'm not sure how well some of the interface design aspects will fit with the SQLite view of things, though. I was wondering if anyone can give me an idea of what I need to impliment in order to have it accessible through Sql.sql.
Bill
/ Brevb�raren
one of the differences between query() and big_query() is that the latter returns an object while the former does not.
it appears to me that sometimes the object interface is wanted even though a normal query would suffice.
i surely would not want to rewrite my apps just because the big_query() interface is not supported. how the actual querying is done is secondary.
greetings, martin.
but do you use big_query in ordinary useage? i don't remember the last time I used big_query()... just query().
bill
On Fri, 19 Dec 2003, Martin[iso-8859-1] B�hr wrote:
one of the differences between query() and big_query() is that the latter returns an object while the former does not.
it appears to me that sometimes the object interface is wanted even though a normal query would suffice.
i surely would not want to rewrite my apps just because the big_query() interface is not supported. how the actual querying is done is secondary.
greetings, martin.
to clarify, my understanding is that big_query was useful in situations where the database would keep the data until it was requested (such as for large queries). then only the data requested would be retrieved. for obvious reasons, SQLite doesn't work that way, and might actually generate more overhead, mitigating one of its primary benefits (speed for small to moderately sized databases).
bill
On Fri, 19 Dec 2003, Bill Welliver wrote:
but do you use big_query in ordinary useage? i don't remember the last time I used big_query()... just query().
bill
On Fri, 19 Dec 2003, Martin[iso-8859-1] B�hr wrote:
one of the differences between query() and big_query() is that the latter returns an object while the former does not.
it appears to me that sometimes the object interface is wanted even though a normal query would suffice.
i surely would not want to rewrite my apps just because the big_query() interface is not supported. how the actual querying is done is secondary.
greetings, martin.
big_query() returns an object which allows me to iterate over the data. this is convenient no matter where the data from the query is stored. hence it is being used even if query() could be used instead.
you could just fake big_query() by executing the query at once, storing it in an array inside the object returned, and then have the methods access the array.
greetings, martin.
you could just fake big_query() by executing the query at once, storing it in an array inside the object returned, and then have the methods access the array.
This is exactly what Sql.sql_result does. You can do
Sql.sql_result(xxx->query("blah"))
to convert a normal query result to a big_query result.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-12-19 21:34: Subject: Re: SQL
big_query() returns an object which allows me to iterate over the data. this is convenient no matter where the data from the query is stored. hence it is being used even if query() could be used instead.
you could just fake big_query() by executing the query at once, storing it in an array inside the object returned, and then have the methods access the array.
greetings, martin.
/ Brevbäraren
oh nice. some things one does not even consider to look for in the docs when one does not expect them to be there. especially not when there is another answer.
greetings, martin.
And Sql.Sql does that for you when you call its big_query and the lower level has no big_query method.
/ Martin Nilsson (saturator)
Previous text:
2003-12-19 21:41: Subject: Re: SQL
you could just fake big_query() by executing the query at once, storing it in an array inside the object returned, and then have the methods access the array.
This is exactly what Sql.sql_result does. You can do
Sql.sql_result(xxx->query("blah"))
to convert a normal query result to a big_query result.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Bill Welliver hww3@riverweb.com writes:
to clarify, my understanding is that big_query was useful in situations where the database would keep the data until it was requested (such as for large queries). then only the data requested would be retrieved. for obvious reasons, SQLite doesn't work that way, and might actually generate more overhead, mitigating one of its primary benefits (speed for small to moderately sized databases).
That's correct. of the "traditional" databases, only miniSQL dos stuff "in memory". Everybody else transfers data as they're fetched. Having both interfaces is needed for Sql.sql, which IIRC uses the one available to emulate the other if missing.
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Kinkie -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Bähr
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
MartinBähr