On Apr 23, 2016 6:21 PM, "Simon Slavin" wrote:
>
>
> On 24 Apr 2016, at 12:58am, Scott Robison wrote:
>
> > For any SQL datastore, the way the data is stored is completely an
> > implementation detail. The SQL engine would be free to serialize all
values
> > to text and store them in 4K pages if
On 04/23/2016 02:10 PM, Richard Hipp wrote:
> Is there a well-defined way to find the name of the application's own
> directory?
The SDL2 library uses this approach
http://www.androwish.org/index.html/artifact/f90b192eadfe588218283717932d35528d84c715?txt=1=1637-1682
i.e. calls
On Sat, Apr 23, 2016 at 12:50 PM, Keith Medcalf wrote:
>
> When a file is a bag-o-bytes rather than a collection-of-records (fixed
> length records at that), there is no longer any need to keep the records
> the same length, hence no need to specify the "reserved length" of things
> (contrary to
On 2016-04-23 4:58 PM, Scott Robison wrote:
> On Sat, Apr 23, 2016 at 12:50 PM, Keith Medcalf
> wrote:
>>
>> When a file is a bag-o-bytes rather than a collection-of-records (fixed
>> length records at that), there is no longer any need to keep the records
>> the same length, hence no need to
On 04/22/2016 02:59 PM, Dominique Devienne wrote:
>> But, if your process has two separate database handles and they both
>> attach "file:data.db?mode=memory=shared" then both handles will be
>> connected to the same in-memory database.
>
> This is exactly what we are doing. Now I keep on reading
On Sat, Apr 23, 2016 at 3:22 PM, Richard Hipp wrote:
> On 4/23/16, Igor Korot wrote:
>> I merely tried to ask why in SQLite one can't have an information
>> about the table field size - that is all.
>
> Answer: That information would consume memory.
Thank you.
That was that simple. ;-)
>
> We
On 4/23/16, Igor Korot wrote:
> I merely tried to ask why in SQLite one can't have an information
> about the table field size - that is all.
Answer: That information would consume memory.
We are under constant pressure to reduce the (already small) memory
footprint of SQLite even further.
> On Sat, 23 Apr 2016 08:56:14 -0400
> "Keith Medcalf" wrote:
>
> > Those things that those other DBMSes do are holdovers to maintain
> > backwards compatibility with the good old days when dinosaurs ruled
> > the earth
> As amusing as your rant is, it's not accurate. Treating columns as
>
On Sat, 23 Apr 2016 08:56:14 -0400
"Keith Medcalf" wrote:
> Those things that those other DBMSes do are holdovers to maintain
> backwards compatibility with the good old days when dinosaurs ruled
> the earth
As amusing as your rant is, it's not accurate. Treating columns as
types is a
On Fri, 22 Apr 2016 19:11:46 -0700
Darren Duncan wrote:
> The general case of a data type definition is an arbitrarily complex
> predicate expression whose parts vary on the base type and other
> factors. Given this, if component details of type definitions were
> split out into their own
Hello,
I tried the scripts but..
createBigTable.sh is beyond the capacity of my system. Instead I used
SQL script like in
www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg08044.html
My point is that the definition of the table is a waste of capacity,
even though it serves on
Hi, Keith,
On Sat, Apr 23, 2016 at 5:56 AM, Keith Medcalf wrote:
>> > What you are seeing there is SQLite just repeating back the type that
>> the CREATE TABLE command used. It is not the type of data SQLite is
>> actually storing.
>
>> > There is no 'varchar' datatype in SQLite. And it never
On 2016/04/23 10:20 AM, Michele Pradella wrote:
> I have an In-Memory DB that is written and read from connections of the
> same process. All good with shared cache, but I found that TableLock
> occur more often on In-Memory than on disk DB, probably because in
> memory we can't use WAL.
>
>
I have an In-Memory DB that is written and read from connections of the
same process. All good with shared cache, but I found that TableLock
occur more often on In-Memory than on disk DB, probably because in
memory we can't use WAL.
Anyway I found the PRAGMA read_uncommitted that from
> > What you are seeing there is SQLite just repeating back the type that
> the CREATE TABLE command used. It is not the type of data SQLite is
> actually storing.
> > There is no 'varchar' datatype in SQLite. And it never truncates
> strings.
> > I think that the best thing for you may be to
On 4/22/16, Christian Werner wrote:
> On 04/22/2016 03:46 PM, Richard Hipp wrote:
>
>> Why isn't /var/tmp or /tmp usable on Android?
>
> There ain't no "/var/tmp" nor "/tmp" on droids. Best of all worst
> alternatives
> is to use the application's own directory or better the subdir "cache"
>
On 23 Apr 2016, at 2:46am, Igor Korot wrote:
> However, what I'm saying is that most DBMS out there do store the size
> of the field.
>
> Even though I issue something like:
>
> CREATE TABLE test( id INTEGER, PRIMARY KEY, test1 VARCHAR(25), test2
> INTEGER(3), test3 FLOAT(25,2) );
>
> if I
On 2016-04-23 1:20 AM, Michele Pradella wrote:
> I have an In-Memory DB that is written and read from connections of the
> same process. All good with shared cache, but I found that TableLock
> occur more often on In-Memory than on disk DB, probably because in
> memory we can't use WAL.
>
> Anyway
On 22 April 2016 at 21:24, Adam Devita wrote:
>
> That said, why is the dropping of a table dependent on the size of
> the table? Does Sqlite have to mark every block of memory it used as
> dropped? (This is obvious for high security mode, but otherwise?)
In rollback journal mode, every
19 matches
Mail list logo
