Exactly!
-Original Message-
From: John Hascall
Sent: Wednesday, October 01, 2014 5:15 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] CLI dump command ignores view dependencies
I think his point was:
...
But, the existing situation where the first is
illegal
I think his point was:
illegal to create a view referring to a non-existing table
AND
illegal to later create a situation where you have a view referring to a
non-existing table
is logical
legal to create a view referring to a non-existing table
AND
legal to later create a situation where you
On Wed, Oct 1, 2014 at 3:53 PM, wrote:
> If it indeed does matter, then shouldn’t dropping view a (in the above
> example) also drop view b, automatically?
>
That assumes view 'a' somehow knows that it is the only consumer of 'b',
which it cannot know. Views from other db files,
On the other hand, creation of a view could ignore the dependencies, and only
check them at run time.
It's curious that the following sequence seems to behave this way:
create view a as select 1;
create view b as select * from a;
select * from b;
.d
drop view a;
.d
select * from b;--Error:
On 1 Oct 2014, at 7:25am, lchis...@paradise.net.nz wrote:
> Any database which has had any maintenance done on its views using any GUI or
> CLI tool could manifest this scenario, and I think it should explicitly
> documented as fixing it is non-trivial.
Nice catch.
It may be possible to fix
Hi all,
People on this list, and the SQLite documentation, say that the .dump command of
the CLI generates SQL which can be .read to rebuild a database.
What is omitted is the fact that the SQL .read may fail if you have created
views referring to other views and they are output in the SQL in the
6 matches
Mail list logo