On Tue, 25 Sep 2007, Maciej Stachowiak wrote:
>
> I agree that the actual I/O to the database should be done up front.
> However, it should be possible to make the conversion from SQLite's
> native data types to JavaScript datatypes lazy (such type conversion can
> have nontrivial cost, especia
On 9/24/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Sun, 23 Sep 2007, David wrote:
> > What if I want to handle the RS by blocks of 100 rows ?
>
> Why wouldn't you just want to do everything?
For the case of a database with a 5M size limit, never.
If app developers, users, and browsers all ag
On 9/25/07, Aaron Boodman <[EMAIL PROTECTED]> wrote:
> On Sep 25, 2007 11:08 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> Ah, that makes sense. A special purpose class for the rows property is
> fine with me. I don't feel that strongly about forEach and friends.
Speaking of forEach, what do
On Sep 25, 2007 11:08 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> I agree that the actual I/O to the database should be done up front.
> However, it should be possible to make the conversion from SQLite's
> native data types to JavaScript datatypes lazy (such type conversion
> can have nontr
On Sep 25, 2007, at 10:23 AM, Aaron Boodman wrote:
On Sep 24, 2007 9:22 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Sun, 23 Sep 2007, Aaron Boodman wrote:
db.executeSQL("select * from person where id = ?", [42],
function(result) {
// result is an array of objects
});
Another issue tha
On Sep 24, 2007 9:22 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Sun, 23 Sep 2007, Aaron Boodman wrote:
> >
> > db.executeSQL("select * from person where id = ?", [42], function(result) {
> > // result is an array of objects
> > });
> >
> > Another issue that this design addresses is that it
On Sun, 23 Sep 2007, Aaron Boodman wrote:
>
> db.executeSQL("select * from person where id = ?", [42], function(result) {
> // result is an array of objects
> });
>
> Another issue that this design addresses is that it avoid blocking the
> UI for IO while iterating the results (all the results
On Sun, 23 Sep 2007, David wrote:
>
> Can someone point me out when the SQLCallback is called exactly ?
> Is it when the ResultSet is full or, as soon as the first row is available ?
I've tried to make this clearer now.
> What if I want to handle the RS by blocks of 100 rows ?
Why wouldn't you
On Wed, 8 Aug 2007, Maciej Stachowiak wrote:
>
> The executeSql() API returns a result synchronously. In general, SQL
> databases may be slow to access since they need to be read from disk,
> and if the database is not open already there's unlikely to be a ready
> cache. This may make it hard t
On Sep 23, 2007 8:28 AM, David <[EMAIL PROTECTED]> wrote:
> Can someone point me out when the SQLCallback is called exactly ?
> Is it when the ResultSet is full or, as soon as the first row is available ?
>
> What if I want to handle the RS by blocks of 100 rows ?
> Wouldn't it be better to let the
Hi,
Can someone point me out when the SQLCallback is called exactly ?
Is it when the ResultSet is full or, as soon as the first row is available ?
What if I want to handle the RS by blocks of 100 rows ?
Wouldn't it be better to let the developer control the threading behaviour
of his I/O accesses
On Sep 20, 2007 1:14 PM, Timothy Hatcher <[EMAIL PROTECTED]> wrote:
> The pain of asynchronous access can be alleviated or even solved with an
> API for transactions, or a group of SQL queries that need be executed in
> order. Commonly, if a transaction fails in the middle, the database
> is roll
The pain of asynchronous access can be alleviated or even solved with
an API for transactions, or a group of SQL queries that need be
executed in order. Commonly, if a transaction fails in the middle, the
database is rolled-back to the state before the transaction started.
There can then be
On Sep 20, 2007 1:22 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> FWIW the async model would probably be easier to implement in the
> short run than worker threads, and we'd be hesitant to implement
> worker threads at all without a clear spec for which APIs should be
> available on worker t
On Aug 8, 2007, at 1:36 PM, Maciej Stachowiak wrote:
http://www.whatwg.org/specs/web-apps/current-work/#executing
The executeSql() API returns a result synchronously. In general, SQL
databases may be slow to access since they need to be read from
disk, and if the database is not open alre
On Aug 8, 2007, at 2:05 PM, Aaron Boodman wrote:
FWIW, We (the gears team) considered adding an async version of our
sql execute() method, but decided against it in favor of improving the
workerpool.
Async APIs work OK for a few requests, but a single logical update to
a local database might b
FWIW, We (the gears team) considered adding an async version of our
sql execute() method, but decided against it in favor of improving the
workerpool.
Async APIs work OK for a few requests, but a single logical update to
a local database might be made up of many SQL statements. Stringing
these all
http://www.whatwg.org/specs/web-apps/current-work/#executing
The executeSql() API returns a result synchronously. In general, SQL
databases may be slow to access since they need to be read from disk,
and if the database is not open already there's unlikely to be a ready
cache. This may mak
18 matches
Mail list logo
