Package: asql Version: 1.6-1 Severity: normal I'm attempting to script the update of an existing asql database with new log entries, but re-saving the database file results in an empty log file. The problem isn't automation specific, it'll blow up quite happily interactively to, as the following snippets can demonstrate:
----->8----- $ cat logs1 [1000 lines of log file] $ cat logs2 [another 1000 lines of log file] $ rm -f logs.sql $ asql asql v1.6 - type 'help' for help. asql> load logs1 Loading: logs1 asql> save logs.sql Saving to : logs.sql asql> quit $ ls -l logs.sql -rw-r--r-- 1 mpalmer mpalmer 326656 Oct 1 15:11 logs.sql $ asql asql v1.6 - type 'help' for help. asql> restore logs.sql asql> load logs2 Loading: logs2 asql> save logs.sql Saving to : logs.sql asql> quit $ ls -l logs.sql -rw-r--r-- 1 mpalmer mpalmer 0 Oct 1 15:11 logs.sql -----8<----- I thought that perhaps one needed to avoid giving a filename to 'save' if you'd restored, so I tried that, too: ----->8----- [as above, up to:] asql> load logs2 Loading: logs2 asql> save Saving to : /home/mpalmer/.asql.db asql> quit $ ls -l /home/mpalmer/.asql.db -rw-r--r-- 1 mpalmer mpalmer 0 Oct 1 15:18 /home/mpalmer/.asql.db $ ls -l logs.sql -rw-r--r-- 1 mpalmer mpalmer 651264 Oct 1 15:11 logs.sql -----8<----- So, if I save a database that previously had some content to a different location (either the default given by 'save' without an argument, or a different location I explicitly specified -- I tried both), then I get an empty database in the new location, and the database I restored from gets a whole pile of extra records. I can live with the latter behaviour, if it's well-documented, but I think that a 'save' causing an empty database anywhere is pretty nasty. My suggested fixes for this would be: * Fix save so that re-saving an existing database (either to the existing location or a new one) doesn't produce an empty database. and one of either: * Documenting the behaviour of the 'restore' command to state that restoring a database effectively makes it the 'live' database for all subsequent load commands (and that a further 'save' is unnecessary); or * Modifying the 'restore' command to make a copy of the restored database to a separate location, and then having the 'load' and 'select' commands operate on that database instead of the file that was restored from, and requiring an explicit 'save' command to persist that modified database (this could be expensive in disk space for large DBs, I know). If any of the current behaviours are documented, then I missed them -- I checked asql(1), README, and the output of 'help', 'help restore', 'help load', and 'help save'. Thanks, - Matt -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable'), (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages asql depends on: ii libdbd-sqlite3-perl 1.29-3 Perl DBI driver with a self-contai ii libterm-readline-gnu-perl 1.20-1 Perl extension for the GNU ReadLin asql recommends no packages. asql suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
