Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-21 Thread RSmith 


On 2014/02/21 11:54, _ph_ wrote:

Suggestion: Warning banner, and a .saveas command that copies the db to a
file.

(I haven't read the entire thread, sorry if this already came up.)


There is usually no call to read an entire thread, unless you decide to 
actually post an opinion, in which case it becomes paramount.



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-21 Thread _ph_ 
Suggestion: Warning banner, and a .saveas command that copies the db to a
file. 

(I haven't read the entire thread, sorry if this already came up.)



--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Proposed-enhancement-to-the-sqlite3-exe-command-line-shell-tp73827p74071.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-11 Thread James K. Lowden 
On Tue, 11 Feb 2014 16:49:50 -0500
Stephen Chrzanowski  wrote:

> I don't like the idea of letting the software decide what should be
> done based on a configuration file.  

Hmm, isn't it the other way around?  Does the user tell the software
what to do via a configuration file?  

~/.sqliterc already exists.  I merely suggested using it, instead of a
compiled-in constant should the user so desire, to determine the
location of the default database.  

> may not even have ${HOME}

I just don't see how that matters to a sqlite3 user working at or
near the command line.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-11 Thread Tim Streater 
On 11 Feb 2014 at 21:49, Stephen Chrzanowski  wrote:

> I don't like the idea of letting the software decide what should be done
> based on a configuration file.

The .sqliterc file already exists, so you're too late.

> Linux and Windows both can isolate processes from each other, be
> completely independent, and not worry about pesky configuration files.
> Yeah most linux distros do have a /home directory, but some 'root only'
> devices don't, or may not even have ${HOME} defined as per James suggested.

Who is going to be running a CLI program on such devices?

> If you're going to go as far as throwing parameters at
> sqlite3.exe/sqlite3.so/sqlite3.whatever to indicate where a configuration file
> is, you might as well start including the database you want to write to.

AIUI, the suggestion is for a change to the CLI program only. And it already 
knows where the .sqliterc configuration file is to be found, at least on OS X. 
I imagine it'll be the same place for linux, I've no idea about Windows.



--
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-11 Thread Stephen Chrzanowski 
Lets not throw honey at the problem when a bear is around.  Some of the
things I've seen in this thread just makes it sound like the kitchen sink
should be included in this application.

I don't like the idea of letting the software decide what should be done
based on a configuration file.  Linux and Windows both can isolate
processes from each other, be completely independent, and not worry about
pesky configuration files.  Yeah most linux distros do have a /home
directory, but some 'root only' devices don't, or may not even have ${HOME}
defined as per James suggested.  If you're going to go as far as throwing
parameters at sqlite3.exe/sqlite3.so/sqlite3.whatever to indicate where a
configuration file is, you might as well start including the database you
want to write to.  With this, you're throwing additional code on a fully
multiplatform compatible application that has to be aware of checks and
balances against every OS this CAN be run on.  Overkill when a simple note
to the user will do.

I'm all for the notification, sans color/colours/fonts.  If needed, throw a
few asterisks before and after a warning indicating that pending a load,
anything done is written to an in-memory database, and be done with it.

I'm not for over-complicating a simple thing that the user needs to be
notified of.  Maybe lose the colors if necessary for some terminals, but
all in all, I think what Richard posted earlier is sufficient for the cause.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-11 Thread Nico Williams 
On Mon, Feb 10, 2014 at 10:30 PM, Simon Slavin  wrote:
> On 11 Feb 2014, at 4:06am, James K. Lowden  wrote:
>
>> ${HOME}/.sqlite/db would be my choice.
>
> Since the objective is not to let a naive user unexpectedly lose the data, it 
> might seem a bad idea to put the file in a directory which is hidden from 
> naive users.

I don't get this.  Why should the user know where it lives when they
can just start the shell and there's the data?

I like James' idea, even though it will be somewhat surprising.

The behavior could be made to be opt-in and then have /etc/skeleton on
*nix distros include the opt-in (or not).  As to Windows... I can see
that double-click detection there might be nice.

Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-11 Thread Stephan Beal 
On Tue, Feb 11, 2014 at 5:06 AM, James K. Lowden
wrote:

> > (1) Detect double-click launch by looking at argc and argv.
>
> Why make this a special case?  If no database name is provided,
> the behavior should be the same regardless of how launched or what OS.
> Easier to explain; easier to understand.
>

And also a potential security regression for those who have grown to (or
have scripts which) expect their ultra-secret data to be discarded by
default. Privacy advocates just love that type of thing: "if you enter the
following SQL into an sqlite3 console, then save your credit card number
there, it will be silently saved in your home directory where other users
can potentially read it."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Keith Medcalf 

If no directory is specified, the current directory should be used.  If no 
filename is specified then no file should be used.

Introduction of magic is very, very, very, very, very, very, very, very, bad.

It is why Steve Ballmer got his ass handed back to him on a platter and Windows 
is in the throws of death, the current version having sold only 26 copies.  No 
one likes illogical magic.

Deliver a clue-by-four to the stupid in blinking red text if you must take pity 
on the addle, but they have to learn something about computers sometime.  Now 
might be the time.  (and if you make blinking red text, then make a way to 
permanently disable it like an environment variable IDIOTMODE=OFF or 
DOWHATISAYANDONLYWHATISAY=YES or MAGIC=OFF or something like that so that 
normal people are not inconvenienced by the need to cater to the clueless by 
arbitrary and illogical behaviour)

>-Original Message-
>From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
>boun...@sqlite.org] On Behalf Of Nico Williams
>Sent: Monday, 10 February, 2014 21:36
>To: General Discussion of SQLite Database
>Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe command-
>line shell
>
>On Mon, Feb 10, 2014 at 10:06 PM, James K. Lowden
><jklow...@schemamania.org> wrote:
>
>James proposes that when no DB is named on the command-line argument
>list then a [user-specific] default be used, and that the user be
>told.
>
>I like it.  I admit that I often rely on the shell keeping no state
>when run with no arguments (I do this to verify statement syntax and
>query plans with simple schemas), but I won't miss that.
>
>I suppose that it's possible that there are applications that rely on
>the shell with no arguments opening an ephemeral DB (they might ATTACH
>other DBs and otherwise rely on any schema statements on the main DB
>having no persistent effect).  That is something to consider, but such
>applications could have a .command in their ~/.sqliterc to override
>this new behavior.  Like James, I prefer that new users observe safe
>behavior.
>
>>> (5) In what folder should the "standard" database file be created?
>>
>> The folder, er, directory should be the user's home directory, located
>> by exactly the same logic that locates ~/.sqliterc.
>>
>>> (4) What should the name of the "standard" database file be?
>>
>> ${HOME}/.sqlite/db would be my choice.
>
>+1
>
>> Other thoughts:
>>
>> 1.  To retain existing behavior, consider making
>>
>> attach database :memory: as main;
>
>+1
>
>> valid SQL in ~/.sqliterc.  As an interesting bonus, support for
>
>Maybe.  Sounds like an accident waiting to happen.
>
>That said, I'd like to be able to create TEMP schema such that it gets
>re-created at DB open time (e.g., temp tables and triggers, so that
>the triggers may use said temp tables without having to source schema
>creation statements from any file).  But that's a different story.
>
>Nico
>--
>___
>sqlite-users mailing list
>sqlite-users@sqlite.org
>http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Nico Williams 
On Mon, Feb 10, 2014 at 10:06 PM, James K. Lowden
 wrote:

James proposes that when no DB is named on the command-line argument
list then a [user-specific] default be used, and that the user be
told.

I like it.  I admit that I often rely on the shell keeping no state
when run with no arguments (I do this to verify statement syntax and
query plans with simple schemas), but I won't miss that.

I suppose that it's possible that there are applications that rely on
the shell with no arguments opening an ephemeral DB (they might ATTACH
other DBs and otherwise rely on any schema statements on the main DB
having no persistent effect).  That is something to consider, but such
applications could have a .command in their ~/.sqliterc to override
this new behavior.  Like James, I prefer that new users observe safe
behavior.

>> (5) In what folder should the "standard" database file be created?
>
> The folder, er, directory should be the user's home directory, located
> by exactly the same logic that locates ~/.sqliterc.
>
>> (4) What should the name of the "standard" database file be?
>
> ${HOME}/.sqlite/db would be my choice.

+1

> Other thoughts:
>
> 1.  To retain existing behavior, consider making
>
> attach database :memory: as main;

+1

> valid SQL in ~/.sqliterc.  As an interesting bonus, support for

Maybe.  Sounds like an accident waiting to happen.

That said, I'd like to be able to create TEMP schema such that it gets
re-created at DB open time (e.g., temp tables and triggers, so that
the triggers may use said temp tables without having to source schema
creation statements from any file).  But that's a different story.

Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Simon Slavin 

On 11 Feb 2014, at 4:06am, James K. Lowden  wrote:

> ${HOME}/.sqlite/db would be my choice.  

Since the objective is not to let a naive user unexpectedly lose the data, it 
might seem a bad idea to put the file in a directory which is hidden from naive 
users.

Just another example of why constructing a default 'safe' directory is so 
difficult.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread James K. Lowden 
On Mon, 10 Feb 2014 10:23:57 -0500
Richard Hipp  wrote:

> Proposed Change To Address The Problem:

Thank you for addressing this.  I for one think you're getting a lot of
unhelpful advice.  A database application that loses data?  As a
feature? 

> (1) Detect double-click launch by looking at argc and argv.  

Why make this a special case?  If no database name is provided,
the behavior should be the same regardless of how launched or what OS.
Easier to explain; easier to understand.  

> (3) Announce the name of the "standard" database file in the banner.

Unnecessary IMO, see next.  

> (5) In what folder should the "standard" database file be created?

The folder, er, directory should be the user's home directory, located
by exactly the same logic that locates ~/.sqliterc. 

> (4) What should the name of the "standard" database file be?

${HOME}/.sqlite/db would be my choice.  

Let's consider the ramifications of these choices.  

Every time sqlite3 is launched without an explicit database name,
${HOME}/.sqlite/db is opened.  The naïve user never loses so much as a
row; whenever the application is opened, yesterday's data are still
there, safe and sound.  In keeping with the principle of "data
independence", the location is unimportant.  SQLite Just Works.  

The inquisitive user could RTFM.  Or, say, type ".help", followed by
".databases".  The distance from the command prompt to the required
information is both short and consistent with other uses of sqlite3.  

The default location is the most likely place on the disk to which the
user has write permissions.  By choosing a dotfile, the name is
normally hidden, yet easily discovered.  

It doesn't interfere with current use or pester the user with still
more text and prompts.  I would prefer to see sqlite3 move in the
direction of quietude.  Already 6 lines stand between command and
prompt:

$ sqlite3 | nl
-- Loading resources from /home/jklowden/.sqliterc

 1  SQLite version 3.7.13 2012-06-11 02:05:22
 2  Enter ".help" for instructions
 3  Enter SQL statements terminated with a ";"
 4  sqlite> 

Other thoughts: 

1.  To retain existing behavior, consider making 

attach database :memory: as main;

valid SQL in ~/.sqliterc.  As an interesting bonus, support for 

detach main 

would remove "main" as a special case.  

2.  Consider a -mem option for those situations when ${HOME} is 0400 or
the user knows he want to discard the database on exit.  

Humbly submitted.  

--jkl


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Gabor Grothendieck 
On Mon, Feb 10, 2014 at 1:56 PM, Petite Abeille
 wrote:
>
> On Feb 10, 2014, at 7:39 PM, Gabor Grothendieck  
> wrote:
>
>> That should have read right join.
>
> My personal opinion? Anyone even considering using a right outer join should 
> be cursed into repeating their first day at high school. For ever. Groundhog 
> Day, The High School Years.
>

Right joins are important since they generalize subscripting.  For
example, if X and Y are data tables (created using the R data.table
package) then X[Y] is a right join of X and Y.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Petite Abeille 

On Feb 10, 2014, at 7:39 PM, Gabor Grothendieck  wrote:

> That should have read right join.  

My personal opinion? Anyone even considering using a right outer join should be 
cursed into repeating their first day at high school. For ever. Groundhog Day, 
The High School Years.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread RSmith 


On 2014/02/10 20:31, Petite Abeille wrote:

On Feb 10, 2014, at 4:23 PM, Richard Hipp  wrote:


Proposed Change To Address The Problem:

What’s the problem exactly? CS101 students distress? That’s way beyond SQLite 
reach.

My 2¢: don’t create a default persistent database. This is not helpful to 
anyone.



I agree 100% on both points, except to say that if a simple change can be found that do not alter the function but can make it work 
better for everyone, then it would be a crime not to implement.


I quite like another poster's idea, Change nothing, but warn when starting sqlite3.exe, not when quitting. An easy function to 
commit an in-memory DB to disk will be great too, though I believe .backup can do this already (though another suggestion to alias 
it to .save have merit). None of this will break current implementations or scripts.



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Gabor Grothendieck 
That should have read right join.  Its a nuisance when you are trying
to show someone SQL and trying to keep things simple that you have to
add the complexity of switching the arguments around.

I am still on 3.7.17 which is the version that currently ships with
the software I am using but its nice to know that I will have rfc4180
when its upgraded.

On Mon, Feb 10, 2014 at 1:26 PM, Petite Abeille
 wrote:
>
> On Feb 10, 2014, at 5:19 PM, Gabor Grothendieck  
> wrote:
>
>> The other features that would make teaching a bit easier would be to support
>> left join explicitly and support the rfc4180 standard for csv files.
>
> Hmmm?
>
> Left join:
> http://www.sqlite.org/syntaxdiagrams.html#join-operator
>
> RFC-4180 compliant .import:
> http://sqlite.org/releaselog/3_8_0.html
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Konrad Hambrick 

All --

My $0.02 is to not change anything except maybe, perhaps printing a warning 
message.

If they want to create a persistent DB, .quit ; and start over with a dbname on 
the command line ...

I am afraid any such change might break existing bash and bat scripts I've got 
'out there in the wild'.

Thanks for letting me pipe-in ...

-- kjh


> -Original Message-
> From: sqlite-users-boun...@sqlite.org 
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf
> Of Richard Hipp
> Sent: Monday, February 10, 2014 12:14 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line 
> shell
> 
> On Mon, Feb 10, 2014 at 1:11 PM, Mike King <making1...@gmail.com> wrote:
> 
> > Why not show the warning on exit only if an in memory database is in use.
> >
> >
> 
> Because on windows, the likely "exit" will be when the user clicks the big
> red X in the upper right-hand corner, closing the terminal window down, so
> there is no opportunity to display a warning nor ask for confirmation.
> 
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread RSmith 


On 2014/02/10 18:22, John McKown wrote:

Being a UNIX (Linux) partisan, and somewhat tacky towards Windows users,
why not go the normal Windows route of having a "pop up" dialog box (or at
least a message) similar to what normal Windows applications say about
possible loss of data. Something along the lines of "You are exiting
sqlite3, but there is data in one or more memory resident tables which will
be lost. Proceed (Y or N)?"


Being a Windows partisan and somewhat untacky to downright loving of all other systems and uses, allow me to explain the way Windows 
works quickly - it has a kernel which runs services and programs, just like unix/linux/etc, and then it has a very standardized very 
elaborate graphical user interface system which attaches graphical areas (commonly known as "Forms") to underlying processes - much 
like OSX etc.


Running a process as a command-line or shell process means it can be really lightweight and devoid of any of the mentioned graphical 
user-interfacy stuff, with the added benefit that, a few specific adaptations aside, you can use much the same C codebase to make it 
run on linux or whatever else, much like the discussed slite3 tool. As such, attaching a pop-up anything to the process requires it 
to have evolved into a GUI-supporting system so it has parent windows to have the popped-up handles attached to - a change which is 
simple, but would see the exe auto-double in size.  So to answer your suggestion - no, that's not a good idea.


To further this point, there must be a quadrillion free full graphical-interface SQLite tools on every OS out there... why on earth 
do students not simply use any of those?


FWIW, my vote goes with the current mainstream opinion, leave as is, warn when quitting, possibly provide a .save command. Forcing 
the shell-window closed (Alt-F4, Click close, Alt-SPACE->C, Task manager, whatever) will steal any opportunity for ever having a 
warning of any kind - but then, this is true for any other shell tool, why would it be a special requirement for sqlite3.exe? I 
don't think anybody would expect to have their DB saved if they forcibly shutdown ANY app, only when exiting normally, one should be 
at least warned of a potential loss.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Adam Devita 
Good day,

I'd rather the warning be in the text when you open the sqlite tool with an
implied in memory database.  Put an extra \n if you want the warning to
stand out.

Adam



On Mon, Feb 10, 2014 at 1:26 PM, Petite Abeille wrote:

>
> On Feb 10, 2014, at 5:19 PM, Gabor Grothendieck 
> wrote:
>
> > The other features that would make teaching a bit easier would be to
> support
> > left join explicitly and support the rfc4180 standard for csv files.
>
> Hmmm?
>
> Left join:
> http://www.sqlite.org/syntaxdiagrams.html#join-operator
>
> RFC-4180 compliant .import:
> http://sqlite.org/releaselog/3_8_0.html
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Petite Abeille 

On Feb 10, 2014, at 4:23 PM, Richard Hipp  wrote:

> Proposed Change To Address The Problem:

What’s the problem exactly? CS101 students distress? That’s way beyond SQLite 
reach.

My 2¢: don’t create a default persistent database. This is not helpful to 
anyone.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Petite Abeille 

On Feb 10, 2014, at 5:19 PM, Gabor Grothendieck  wrote:

> The other features that would make teaching a bit easier would be to support
> left join explicitly and support the rfc4180 standard for csv files.

Hmmm? 

Left join:
http://www.sqlite.org/syntaxdiagrams.html#join-operator

RFC-4180 compliant .import:
http://sqlite.org/releaselog/3_8_0.html


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Richard Hipp 
On Mon, Feb 10, 2014 at 1:11 PM, Mike King  wrote:

> Why not show the warning on exit only if an in memory database is in use.
>
>

Because on windows, the likely "exit" will be when the user clicks the big
red X in the upper right-hand corner, closing the terminal window down, so
there is no opportunity to display a warning nor ask for confirmation.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Mike King 
Why not show the warning on exit only if an in memory database is in use.
Likewise by default open in memory unless a path is specified.

On Monday, 10 February 2014, Richard Hipp  wrote:

> On Mon, Feb 10, 2014 at 12:51 PM, > wrote:
>
> > I second the idea of a kind of "WARNING: All your work will be lost, are
> > you sure you want to quit? (y/N)" on trying to exit, but *ONLY* if the
> > application was started by (double-)clicking on it, otherwise the warning
> > will be a nuisance when running test scripts.
> >
>
> I think I know how to detect a double-click launch versus a command-line
> launch on windows.  But I don't know how to do this, or even if it is
> possible to do, on Mac or Linux.  Anybody have any ideas?
>
>
> --
> D. Richard Hipp
> d...@sqlite.org 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org 
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Jay Kreibich 

On Feb 10, 2014, at 10:20 AM, Jay Kreibich  wrote:

> On Feb 10, 2014, at 10:15 AM, Richard Hipp  wrote:
> 
>> What if, instead of opening a standard database, the sqlite3.exe
>> command-line shell just issued a warning message reminding the user that
>> they are working on a transient in-memory database and suggesting the use
>> of the ".open" command to connect to a persistent on-disk database.  Like
>> in this patch:
>> 
>> http://www.sqlite.org/src/info/90e9deae4a
> 
> 
> I think a warning is the best solution.  In addition to the .open reminder,  
> I would add a ".save" shell command that dumps the current main database to a 
> file.  This might be a simple alias to the .backup command.
> 

Actually... let me amend this.  I like the suggestion of having an .quit 
warning when "main" is an in-memory database.

In addition, I'd suggest a .save shell command that dumps the current main 
database to disk, and then opens the file as the new main.  This would provide 
a "document" model that many desktop users are already used to dealing with.


>   -j
> 
> --  
> Jay A. Kreibich < J A Y  @  K R E I B I.C H >
> 
> "Intelligence is like underwear: it is important that you have it, but 
> showing it to the wrong people has the tendency to make them feel 
> uncomfortable." -- Angela Johnson
> 
> 
> 
> 

--  
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it, but showing 
it to the wrong people has the tendency to make them feel uncomfortable." -- 
Angela Johnson




___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Stephen Chrzanowski 
I was just going to suggest that John.  Short of hitting CTRL-C to break
out of the program, the user may have to "double-quit" if no file path has
been given to be saved to, just for confirmation.

> .q
!!Warning - In-Memory Database not saved.  Quit again to exit without saving
> .q
C:\Users\Default User> _

Or, use ".qq" to force quit and ignore the warning.


On Mon, Feb 10, 2014 at 11:22 AM, John McKown
wrote:

> Being a UNIX (Linux) partisan, and somewhat tacky towards Windows users,
> why not go the normal Windows route of having a "pop up" dialog box (or at
> least a message) similar to what normal Windows applications say about
> possible loss of data. Something along the lines of "You are exiting
> sqlite3, but there is data in one or more memory resident tables which will
> be lost. Proceed (Y or N)?"
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread John McKown 
Being a UNIX (Linux) partisan, and somewhat tacky towards Windows users,
why not go the normal Windows route of having a "pop up" dialog box (or at
least a message) similar to what normal Windows applications say about
possible loss of data. Something along the lines of "You are exiting
sqlite3, but there is data in one or more memory resident tables which will
be lost. Proceed (Y or N)?"


On Mon, Feb 10, 2014 at 10:15 AM, Richard Hipp  wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.  Like
> in this patch:
>
>  http://www.sqlite.org/src/info/90e9deae4a
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Jay Kreibich 

On Feb 10, 2014, at 10:15 AM, Richard Hipp  wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.  Like
> in this patch:
> 
> http://www.sqlite.org/src/info/90e9deae4a


I think a warning is the best solution.  In addition to the .open reminder,  I 
would add a ".save" shell command that dumps the current main database to a 
file.  This might be a simple alias to the .backup command.

  -j

--  
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it, but showing 
it to the wrong people has the tendency to make them feel uncomfortable." -- 
Angela Johnson




___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread David Bicking 
The first time I saw sqlite demonstrated at a linux user group, the presenter 
didn't realize he was using a memory database. I had to explain why all his 
work was lost, then proceeded to continue the demo since I knew more about the 
product. (This was years ago, I think we were still at sqlite 2 at the time.)

Personally, I don't like the idea of a default db. I would rather see a warning 
message sent to the console if no filename was specified saying that data is 
being saved in memory and will be lost on exit. And perhaps suggesting how to 
open a file if that is how they want to proceed.

I really don't like a bizarre solution that has sqlite3.exe or (sqlite3 on 
linux/mac) behaving differently between a double click or from the command 
line. That just seems wrong to me.

David


On Mon, 2/10/14, Stephan Beal <sgb...@googlemail.com> wrote:

 Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line 
shell
 To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
 Date: Monday, February 10, 2014, 10:46 AM
 
 On Mon, Feb 10, 2014 at
 4:41 PM, Simon Slavin <slav...@bigfraud.org>
 wrote:
 
 > Why ?  I
 suspect some Mac user would find it just as useful.  And
 then why
 > leave Unix users out ?
 >
 
 Speaking
 as a member of the Unix-only crowd: please don't! While
 i admit
 that the current behaviour has
 caused minor amounts of annoyance on my part
 (my own fault, as i've been using it long
 enough to know better), i also
 feel that the
 current behaviour is "correct." i think it's
 an interesting
 idea for Windows, though.
 Don't have an opinion on Apple installations.
 
 If it could be configured via
 environment variable, i'd be happy to see it
 in Unix, too. e.g. SQLITE3_DEFAULT_DB, if set
 to a non-empty string, would
 be the db which
 gets automatically opened at startup IFF 1==argc (or some
 similar heuristic - maybe always load it if no
 filename args are provided).
 
 
 -- 
 -
 stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 "Freedom is sloppy. But since
 tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom
 will have to do." -- Bigby Wolf
 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Dominique Devienne 
On Mon, Feb 10, 2014 at 5:15 PM, Richard Hipp  wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.  Like
> in this patch:
>
>  http://www.sqlite.org/src/info/90e9deae4a


Sounds better to me. Although I'd still prefer a terser 1-liner is
possible. --DD
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Richard Hipp 
What if, instead of opening a standard database, the sqlite3.exe
command-line shell just issued a warning message reminding the user that
they are working on a transient in-memory database and suggesting the use
of the ".open" command to connect to a persistent on-disk database.  Like
in this patch:

 http://www.sqlite.org/src/info/90e9deae4a


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Gabor Grothendieck 
On Mon, Feb 10, 2014 at 10:23 AM, Richard Hipp  wrote:
> The Problem:
>
> Many new users (especially university students taking a "database 101"

The other features that would make teaching a bit easier would be to support
left join explicitly and support the rfc4180 standard for csv files.

> class) download the "sqlite3.exe" file from the SQLite website,
> double-click on the "sqlite3" icon to get a command-line shell, then start
> typing SQL statements.  But when they exit the shell, they are distressed
> to discover that their database has disappeared.
>
> Proposed Change To Address The Problem:
>
> When launching sqlite3.exe with a double-click, have it open a standard
> database in a standard place instead of an in-memory database as you would
> get when launching sqlite3.exe with no arguments.  Possibly also give
> additional hints, such as references to the ".open" command, when launching
> by double-click.
>
> (1) Detect double-click launch by looking at argc and argv.  On a
> double-click launch, argc==1 and argv[0] contains the full pathname of the
> executable.  On a command-line launch, argv[0] contains whatever the user
> typed, which is usually not the full pathname
>

I assume that means that if you do not keep sqlite3 on your path then you must
use:

   /path/to/sqlite3 :memory:

to call sqlite3 with an in-memory database. I am not so enthusiastic about this.

How about as an alternative that it works as it does now but when you
exit it asks you
if you want to save the database.  That seems more consistent with how
other programs
(editors, word processors, spreadsheets, etc.) work.

> (2) This change would be for Windows only.  The code to implement it would
> be enclosed in #ifdef _WIN32 ... #endif
>
> (3) Announce the name of the "standard" database file in the banner.
>
> Questions:
>
> (4) What should the name of the "standard" database file be?
>
> (5) In what folder should the "standard" database file be created?
>

%appdata%\sqilte
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Simon Slavin 

On 10 Feb 2014, at 4:15pm, Richard Hipp  wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.

I find that equally acceptable, given the difficulty of squeezing in the 'Guess 
the acceptable path' routine at this stage.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Dominique Devienne 
On Mon, Feb 10, 2014 at 4:23 PM, Richard Hipp  wrote:

> Proposed Change To Address The Problem:
>
> When launching sqlite3.exe with a double-click, have it open a standard
> database in a standard place instead of an in-memory database as you would
> get when launching sqlite3.exe with no arguments.  Possibly also give
> additional hints, such as references to the ".open" command, when launching
> by double-click.
>

Personally, I don't care much for this change... I noticed you didn't ask
for +1 / -1 on this, but most REPLs behave like sqlite3 does now, i.e. pure
in-memory changes, and you need to explicitly do something to persist your
experimentations. My $0.02. --DD

Questions:
>
> (4) What should the name of the "standard" database file be?
>

In keeping with sqlite_master, I'd name it sqlite_default.db


> (5) In what folder should the "standard" database file be created?
>

It depends on the Windows version I'm afraid. On Win7,
%HOMEDRIVE%\%HOMEPATH% seems like a sensible default, or perhaps
%USERPROFILE% too. Didn't remember the previous Windows / DOS equivalents
for Vista, XP, and earlier. --DD

C:\Users\DDevienne>set USER
USERDNSDOMAIN=...
USERDOMAIN=...
USERNAME=DDevienne
USERPROFILE=C:\Users\DDevienne

C:\Users\DDevienne>set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\DDevienne
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Stephan Beal 
On Mon, Feb 10, 2014 at 4:41 PM, Simon Slavin  wrote:

> Why ?  I suspect some Mac user would find it just as useful.  And then why
> leave Unix users out ?
>

Speaking as a member of the Unix-only crowd: please don't! While i admit
that the current behaviour has caused minor amounts of annoyance on my part
(my own fault, as i've been using it long enough to know better), i also
feel that the current behaviour is "correct." i think it's an interesting
idea for Windows, though. Don't have an opinion on Apple installations.

If it could be configured via environment variable, i'd be happy to see it
in Unix, too. e.g. SQLITE3_DEFAULT_DB, if set to a non-empty string, would
be the db which gets automatically opened at startup IFF 1==argc (or some
similar heuristic - maybe always load it if no filename args are provided).


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell

2014-02-10 Thread Simon Slavin 

On 10 Feb 2014, at 3:23pm, Richard Hipp  wrote:

> When launching sqlite3.exe with a double-click, have it open a standard
> database in a standard place instead of an in-memory database as you would
> get when launching sqlite3.exe with no arguments.  Possibly also give
> additional hints, such as references to the ".open" command, when launching
> by double-click.

If the shell does have to make up its own filepath it should tell the user what 
it did, where to find the path, and perhaps also how to specify their own path 
in future.

> [snip] (2) This change would be for Windows only.

Why ?  I suspect some Mac user would find it just as useful.  And then why 
leave Unix users out ?

> (5) In what folder should the "standard" database file be created?


I suspect the problem is knowing where a 'safe' location would be to create a 
file.  Could this be added as a variable inside the VFS ?  The VFS for HFS+ 
would presumably be able to assume you are on a Mac and produce a 
Mac-appropriate default pathname.  The VFS used inside an Android phone would, 
again, be a good place to do it.

Is that how the path for temporary files (not journal files, but /really/ 
temporary files) is decided ?

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users