Re: [sqlite] fixing time-warp

Is that a philosophical question? :) On Mon, Nov 3, 2014 at 5:52 PM, Richard Hipp wrote: > On Mon, Nov 3, 2014 at 8:46 PM, E. Timothy Uy wrote: > > > Ok, I now see that you intentionally left 2 time-warps in place. It would > > be helpful to make that as a note for exporting to git. > > > > Why

Re: [sqlite] fixing time-warp

On Mon, Nov 3, 2014 at 8:46 PM, E. Timothy Uy wrote: > Ok, I now see that you intentionally left 2 time-warps in place. It would > be helpful to make that as a note for exporting to git. > Why would I want to export the SQLite history to Git? -- D. Richard Hipp d...@sqlite.org _

Re: [sqlite] fixing time-warp

Guess my photo got blocked - https://www.sqlite.org/src/timeline?c=2010-09-28+20:26:44 shows the time-warp but also the tag messages fixing them (which I guess you later unfixed in the db). On Mon, Nov 3, 2014 at 5:46 PM, E. Timothy Uy wrote: > Ok, I now see that you intentionally left 2 time-wa

Re: [sqlite] fixing time-warp

Ok, I now see that you intentionally left 2 time-warps in place. It would be helpful to make that as a note for exporting to git. It is also confusing that the tags are there showing that they were fixed. On Mon, Nov 3, 2014 at 5:44 PM, E. Timothy Uy wrote: > Dear Richard, > > It is strange, but

Re: [sqlite] fixing time-warp

Dear Richard, It is strange, but if you look at the timeline image I sent (second email), your time-warp tag changes are clearly there but did not stick on objid 35450 and 35460. I just manually did mine on this end (following your same times) and it is now ok, though I feel a bit dirty changing c

Re: [sqlite] fixing time-warp

On Mon, Nov 3, 2014 at 8:13 PM, E. Timothy Uy wrote: > I found some posts in the past describing fixing time-warps using tags. How > does this process get initiated? I found two while trying to export to .git > The test_timewarps webpage will show them all to you. Example: http://www.sql

[sqlite] fixing time-warp

I found some posts in the past describing fixing time-warps using tags. How does this process get initiated? I found two while trying to export to .git sqlite> SELECT l.*, ep.mtime, ec.mtime FROM plink l LEFT JOIN event ep ON pid = ep.objid LEFT JOIN event ec ON cid = ec.objid WHERE ep.mtime > ec.

Re: [sqlite] Index without backing table

On Mon, 03 Nov 2014 11:50:17 +0200 Paul wrote: > > > Would be nice to have ability to store both key and payload in the > > > index. (Let's call it index-only table) > > > This could be a feature that sets some limitations on a table, > > > like being unable to have more than one index or ineffic

Re: [sqlite] Index without backing table

3 November 2014, 13:56:36, by "Richard Hipp" : > On Mon, Nov 3, 2014 at 6:48 AM, Clemens Ladisch wrote: > > > Paul wrote: > > > Are additional indices, created for WITHOUT ROWID, potentially less > > > efficient and more cumbersome? > > > > For tables with a rowid, the index stores the indexe

Re: [sqlite] Index without backing table

On Mon, Nov 3, 2014 at 6:48 AM, Clemens Ladisch wrote: > Paul wrote: > > Are additional indices, created for WITHOUT ROWID, potentially less > > efficient and more cumbersome? > > For tables with a rowid, the index stores the indexed columns and the > rowid. For WITHOUT ROWID tables, the index s

Re: [sqlite] Index without backing table

3 November 2014, 13:48:30, by "Clemens Ladisch" : > Paul wrote: > > Are additional indices, created for WITHOUT ROWID, potentially less > > efficient and more cumbersome? > > For tables with a rowid, the index stores the indexed columns and the > rowid. For WITHOUT ROWID tables, the index sto

Re: [sqlite] Index without backing table

Paul wrote: > Are additional indices, created for WITHOUT ROWID, potentially less > efficient and more cumbersome? For tables with a rowid, the index stores the indexed columns and the rowid. For WITHOUT ROWID tables, the index stores the indexed columns and the primary key. Regards, Clemens __

Re: [sqlite] Index without backing table

> > On 3 Nov 2014, at 9:50am, Paul wrote: > > > So, to be clear, WITHOUT ROWID table will have it's PRIMARY KEY > > as a replacement for ROWID and table itself is an index? > > It would appear that the answer is "yes". I'm not going to go beyond the > official documentation at > >

Re: [sqlite] Index without backing table

On 3 Nov 2014, at 9:50am, Paul wrote: > So, to be clear, WITHOUT ROWID table will have it's PRIMARY KEY > as a replacement for ROWID and table itself is an index? It would appear that the answer is "yes". I'm not going to go beyond the official documentation at

Re: [sqlite] Index without backing table

> > > Would be nice to have ability to store both key and payload in the > > index. (Let's call it index-only table) > > This could be a feature that sets some limitations on a table, like > > being unable to have more than one index or inefficient table scans, > > but it will also give some adva