I as well disagree that "the higher language, the better". The bloat .NET
adds to the application size for both processing, memory and drive usage is
astronomical. Its like going back to Visual Basic and including the
interpreter in your "compiled" application with your source code basically
Bottom line point, the general "feeling" of that page is to dissuade people
from even CONSIDERING using SQLite for future enhancements (Considering the
age of that page). I won't get on board with that.
What I meant by "common sense" is more towards the hardware the software is
going to be used
On Sun, Jun 14, 2015 at 1:19 PM, Richard Hipp wrote:
> On 6/14/15, Scott Hess wrote:
>> SQLite essentially gives you a set of
>> b-trees with syntactic sugar over them,
>
> SQL (and I speak in general terms here, not just of SQLite) provides
> way more than syntactic sugar over b-trees. The
Quick note. DB Browser 3.7.0 for SQLite has been released: :)
https://github.com/sqlitebrowser/sqlitebrowser/releases/tag/v3.7.0
Win + OSX binaries are there, as is the source tarball. Ubuntu PPA
should be done in a day or two, and hopefully the FreeBSD port will
updated in the near future
> On Jun 14, 2015, at 4:01 PM, david at andl.org wrote:
>
> First, I added a RECURSE() function to Andl, similar to the CTE in SQLite.
Nice.
> The Mandelbrot algorithm looks like this.
Could we see something more, hmmm, pedestrian? Perhaps a simple recursive
query, showing, say, all the
On 14 Jun 2015, at 5:39pm, Mel Llaguno wrote:
> We have an application with embedded SQLite 3.6.14.2 which is being accessed
> by multiple processes. These processes connect to the database with a BEGIN
> IMMEDIATE TRANSACTION. Under what circumstances, if any, can database
> corruption
On 14 Jun 2015, at 4:43pm, Stephen Chrzanowski wrote:
> Most of that looks to be more like common sense things rather than SQLite
> specific, so why they're calling out SQLite, I've no idea.
Because the SQLite engine is part of FireFox, and SQLite calls are very easy to
do from parts of, and
On 14 Jun 2015, at 4:09pm, James K. Lowden wrote:
> Simon Slavin wrote:
>
>> There are plenty of queries which can be expressed in a SQL database
>> but can't be answered without a computer which can reprogram itself
>
> Are there? Do you mean there are SQL queries like that? Or do you
>
We have an application with embedded SQLite 3.6.14.2 which is being accessed by
multiple processes. These processes connect to the database with a BEGIN
IMMEDIATE TRANSACTION. Under what circumstances, if any, can database
corruption actually occur (ruling out filesystem instability and power
On 14 Jun 2015, at 2:08pm, Jean Chevalier wrote:
> Somewhat contradictory the Mozilla Foundation being a member of the SQLite
> Consortium while their performance wiki prominently features a warning to
> developers against using SQLite allegedly for performance reasons. Guard me
> from my
The irony of your comment (which I entirely agree with) is that because
SQLite (and similar) does so much incredibly important stuff for you, it
ends up being difficult for programmers to use it, especially the lower
level the programming is. They don't understand the model of how the system
On 6/14/15, Scott Hess wrote:
> SQLite essentially gives you a set of
> b-trees with syntactic sugar over them,
SQL (and I speak in general terms here, not just of SQLite) provides
way more than syntactic sugar over b-trees. The syntactic sugar over
b-trees part is the *least* of the many
On 6/14/2015 3:00 PM, Simon Slavin wrote:
> The result is that that higher level the language you write in, the better.
I disagree. The use of languages higher than C result in slow
bloated code. A language that calls a language that calls a
language. Simple programs become multi-megabyte
Somewhat contradictory the Mozilla Foundation being a member of the SQLite
Consortium while their performance wiki prominently features a warning to
developers against using SQLite allegedly for performance reasons. Guard me
from my friends...
On Sun, 14 Jun 2015, Richard Hipp wrote:
> SQL (and I speak in general terms here, not just of SQLite) provides way
> more than syntactic sugar over b-trees. The syntactic sugar over b-trees
> part is the *least* of the many advantages of SQL. Other more important
> features include:
Very
Most of that looks to be more like common sense things rather than SQLite
specific, so why they're calling out SQLite, I've no idea. Also, this doc
was last modified more than a year ago. Stuff has changed both within FF
as well as SQlite since then.
I've just deleted the blog I was going to
On Fri, 12 Jun 2015 01:45:50 +0100
Simon Slavin wrote:
> There are plenty of queries which can be expressed in a SQL database
> but can't be answered without a computer which can reprogram itself
Are there? Do you mean there are SQL queries like that? Or do you
mean there are such queries
Jean Chevalier wrote:
> Somewhat contradictory the Mozilla Foundation being a member of the
> SQLite Consortium while their performance wiki prominently features a
> warning to developers against using SQLite allegedly for performance
> reasons. Guard me from my friends...
>
>
For various reasons I've ended up as the SQLite rep w/in Chromium, and
I bookmarked that page awhile back to periodically revisit. People
often seem to believe that SQLite magically solves tons of problems
with their persistence layer, without realizing that many of their
assumptions are based on
On Jun 14, 2015 9:43 AM, "Stephen Chrzanowski" wrote:
>
> Most of that looks to be more like common sense things rather than SQLite
> specific, so why they're calling out SQLite, I've no idea. Also, this doc
> was last modified more than a year ago. Stuff has changed both within FF
> as well as
20 matches
Mail list logo
