Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On Fri, Mar 13, 2020 at 1:15 AM Jens Alfke wrote: > > > On Mar 12, 2020, at 1:17 PM, Richard Hipp wrote: > > > > I have set up an on-line forum as a replacement for this mailing list: > > Oh crap. > > > The Forum is powered by Fossil. > > I appreciate that you like to 'eat your own dog food'.

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

The nice thing about web browsers, you can apply your own styling. There's extensions that help with that, like StyleBot. Wout. On Fri, Mar 13, 2020 at 1:05 AM Keith Medcalf wrote: > > > Uck. That is the most horrible looking thing I have ever seen in my life. > Good luck with it. > > > -- >

Re: [sqlite] New SQLite Forum requires Javascript?

Hi, I normally wouldn't do this on the internet, but this mailing list goes deep. Not sure how that will go now that we have to use the forum, but here goes. JavaScript makes websites much nicer to work with, by a wide margin, especially those with lots of interaction like forums. Furthermore,

[sqlite] New SQLite Forum requires Javascript?

Richard Hipp wrote: The Forum is powered by Fossil. It has been in active use in the Fossil community for a couple of years, and has worked well. Is there a way to use this without running the Javascript? ___ sqlite-users mailing list

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

I've read a bunch of the posts here, and quite honestly, I'm kind of looking forward to having Fossil send me notes that messages have been added, then, if I want to reply, I just log into the site and do the reply. I'm not 100% sure about the anon sending to Fossil, if that's a thing I thought I

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On Mar 12, 2020, at 6:15 PM, Jens Alfke wrote: > > I strongly disagree with your using a homemade forum rather than something > like Discourse. Unlike SQLite proper, the Fossil project accepts outside contributions without a whole lot of gatekeeping. I myself have made a few improvements to

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On March 12, 2020 8:15:15 p.m. EDT, Jens Alfke wrote: > > >> On Mar 12, 2020, at 1:17 PM, Richard Hipp wrote: >> >> I have set up an on-line forum as a replacement for this mailing >list: > >Oh crap. > >> The Forum is powered by Fossil. > >I appreciate that you like to 'eat your own dog

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On March 12, 2020 8:06:47 p.m. EDT, Petite Abeille wrote: > >Also, would it be possible to actually mark such emails to include >proper List Header Fields, e.g.: I had the same thought, but would that really be appropriate? Unless you could post to it like a list, anyway. -- J. King

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

> On Mar 12, 2020, at 1:17 PM, Richard Hipp wrote: > > I have set up an on-line forum as a replacement for this mailing list: Oh crap. > The Forum is powered by Fossil. I appreciate that you like to 'eat your own dog food'. However, I strongly disagree with your using a homemade forum

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

> On Mar 13, 2020, at 01:04, Keith Medcalf wrote: > > Uck. That is the most horrible looking thing I have ever seen in my life. > Good luck with it. If only this was confine to the esthetics. But yes, horrible sums it up. ___ sqlite-users

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

> On Mar 13, 2020, at 00:54, BohwaZ wrote: > > So that people wishing to use emails could still do it by subscribing > to alerts and then replying to notifications. Also, would it be possible to actually mark such emails to include proper List Header Fields, e.g.: List-Id: List Header

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

Uck. That is the most horrible looking thing I have ever seen in my life. Good luck with it. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users On >Behalf Of Richard Hipp

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

Kia ora, Like with the Fossil list I did subscribe and switch to the forum, but wouldn't it be possible to add the ability in Fossil to handle incoming email replies to forum posts? So that people wishing to use emails could still do it by subscribing to alerts and then replying to

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

Hello Richard ! I like the concept of fossil including the forum functionality ! With that said we are in a database forum and most of us know that one common problem/task with databases is migration, there is any plan/attempt to migrate the actual mailing list to the new fossil forum ?

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

> On Mar 12, 2020, at 21:17, Richard Hipp wrote: > > a replacement for this mailing list: Tragic. Oh well. Anyhow, thanks for SQLite itself :) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On Mar 12, 2020, at 2:59 PM, no...@null.net wrote: > > I would like to add my resistance "vote." If experience on the Fossil mailing list is any guide, this mailing list will be a ghost town soon. There have been just a few threads on the mailing list in the years since we started the forum,

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On 3/12/20, no...@null.net wrote: > I am wondering what (apparently invisible) > anti-spam features are present. I will be happy to discuss that, and any other questions you have, on the Forum. :-) -- D. Richard Hipp d...@sqlite.org ___ sqlite-users

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

On Thu Mar 12, 2020 at 04:17:59PM -0400, Richard Hipp wrote: > I have set up an on-line forum as a replacement for this mailing list: > > https://sqlite.org/forum > https://www.sqlite.org/forum/forumpost/a6a27d79ac I know this topic has already been discussed deeply on this list, but I

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

They can subscribe to the forum too. :) On Thu, Mar 12, 2020, 2:40 PM Simon Slavin wrote: > Well, that'll annoy the nabble people. And I can live with that. > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org >

Re: [sqlite] New SQLite Forum established - this mailing list is deprecated

Well, that'll annoy the nabble people. And I can live with that. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] New SQLite Forum established - this mailing list is deprecated

I have set up an on-line forum as a replacement for this mailing list: https://sqlite.org/forum https://www.sqlite.org/forum/forumpost/a6a27d79ac Please consider subscribing to the new Forum. The intent is that the forum will eventually replace this mailing list. The Forum is powered

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

>So is "julianday('now')" non-deterministic while "julianday()" _is_ >deterministic? That seems a little weird considering they're the same >thing... right? Yes. Same as "datetime(julianday(), '+1 day')" and datetime(datetime(), '+1 day') are deterministic but "datetime('now', '+1 day')" is not

Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short-circuit sometimes

On 3/12/20, Doug wrote: > > Something triggered me when I looked at the generated code: you use the > contents of register 2 for the constant value each time through the loop. > What if the select looks like this, with more than one function call in the > coalesce? Do you handle it properly? > >

Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short-circuit sometimes

Thanks, Richard. Something triggered me when I looked at the generated code: you use the contents of register 2 for the constant value each time through the loop. What if the select looks like this, with more than one function call in the coalesce? Do you handle it properly? SELECT

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

> Alternatively, you can use the new GENERATED ALWAYS AS (...) STORED to make > it an automatically updated stored field and you do not need triggers at all, > just a version of SQLite3 that does generated columns (version 3.31.0 from > 2020-01-22 or later). > > create table MyData > ( > id

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

On Thursday, 12 March, 2020 09:37, David Blake wrote: >What stops the >UPDATE ports SET timeofday = CURRENT_TIMESTAMP WHERE id = NEW.id ; >from also triggering the AFTER UPDATE ON recursively? >Perhaps a pragma or inSQLite are triggers non-recursive by default? >I am using (now I have by

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

On 12 Mar 2020, at 3:36pm, David Blake wrote: > What stops the > UPDATE ports SET timeofday = CURRENT_TIMESTAMP WHERE id = NEW.id ; > from also triggering the AFTER UPDATE ON recursively? > > Perhaps a pragma or inSQLite are triggers non-recursive by default? Bingo.

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

> What stops the > UPDATE ports SET timeofday = CURRENT_TIMESTAMP WHERE id = NEW.id ; > from also triggering the AFTER UPDATE ON recursively? > > Perhaps a pragma or inSQLite are triggers non-recursive by default? > > I am using (now I have by semi-colons right) > CREATE TRIGGER tgrUpdate AFTER

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

>Thanks Andy >> In addition, the role of the "when" clause is unclear. Is it necessary? >> >> I don't think it is. I have a very similar trigger which I've been >> using for several years And it doesn't have the where... >> >> CREATE TRIGGER [UpdatePortTime] AFTER UPDATE ON ports FOR EACH ROW

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

Thanks Andy > In addition, the role of the "when" clause is unclear. Is it necessary? > > I don't think it is. I have a very similar trigger which I've been using > for several years > And it doesn't have the where... > > CREATE TRIGGER [UpdatePortTime] AFTER UPDATE ON ports > FOR EACH ROW >

Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short-circuit sometimes

On 3/12/20, Doug wrote: > Richard, what does the explain look like with your code change, please. Test case: CREATE TABLE t1(a); explain SELECT coalesce(a, abs(-9223372036854775808)) FROM t1; Before the change: addr opcode p1p2p3p4 p5 comment

Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short-circuit sometimes

Richard, what does the explain look like with your code change, please. Doug > -Original Message- > From: sqlite-users > On Behalf Of Richard Hipp > Sent: Thursday, March 12, 2020 3:09 AM > To: SQLite mailing list > Subject: Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short- >

Re: [sqlite] Corrupted FTS5 index? disk image is malformed - Part II

According to your pragmas you have vacuum done once in a while. Vacuum alters the rowid values of a table, unless the rowid is declared explicitly as "INTEGER PRIMARY KEY" (probably not the case here). See from here : /If the rowid is not aliased by

Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short-circuit sometimes

On 3/12/20, Hick Gunter wrote: > Exactly what I gained from the EXPLAIN output. > > The SQL "compiler" is extracting the constant expression ABS(...) and > evaluating it in the program prolog (where schema is checked and locks > taken). See instructions 11 and 12 Exactly. SQLite tries to factor

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

>On 12/03/2020 08:47, David Blake wrote: >> I'm looking for an easy way to maintain a last updated column for each >> record in several tables and considering if using a triggers is viable. >> >> I thought that defining a trigger like this on each table would work >> >> CREATE TRIGGER

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

On 12/03/2020 08:47, David Blake wrote: I'm looking for an easy way to maintain a last updated column for each record in several tables and considering if using a triggers is viable. I thought that defining a trigger like this on each table would work CREATE TRIGGER my_update_trigger BEFORE

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

Ha, my error - missing ";" in the UPDATE clause but I was blind. On Thu, 12 Mar 2020 at 08:18, David Blake wrote: > Thanks for such a swift reply, good to know that it should work (without > typos) > > >Thank you very much for keeping the error message secret. > > near "END": syntax error: > >

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

Thanks for such a swift reply, good to know that it should work (without typos) >Thank you very much for keeping the error message secret. near "END": syntax error: I'm testing out ideas using DB Browser, but will try in my app and see if this is just a DB Browser issue On Thu, 12 Mar 2020 at

Re: [sqlite] Maintaing a Last updated timestamp column using triggers

David Blake wrote: > CREATE TRIGGER my_update_trigger BEFORE UPDATE ON My_table > FOR EACH ROW WHEN NEW.lastupdated < OLD. lastupdated > BEGIN > UPDATE song SET lastupdated = DATETIME('now') WHERE id = NEW.id > END > > The WHEN clause is an attempt to avoid infinite recursion that

Re: [sqlite] [EXTERNAL] Re: COALESCE() does not short-circuit sometimes

Exactly what I gained from the EXPLAIN output. The SQL "compiler" is extracting the constant expression ABS(...) and evaluating it in the program prolog (where schema is checked and locks taken). See instructions 11 and 12 asql> explain select coalesce((SELECT

[sqlite] Maintaing a Last updated timestamp column using triggers

I'm looking for an easy way to maintain a last updated column for each record in several tables and considering if using a triggers is viable. I thought that defining a trigger like this on each table would work CREATE TRIGGER my_update_trigger BEFORE UPDATE ON My_table FOR EACH ROW WHEN