Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41A4B4EF.809@sbcglobal.net>
Date: Wed, 24 Nov 2004 08:21:03 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Unable to restore a Derby database [SOLVED?]
References: <41A28890.1040203@thatone.com> <41A38825.6070909@sbcglobal.net>
 <41A40CDB.1030808@thatone.com> <41A40FBA.9000506@thatone.com>
 <41A414D8.5090205@Sun.COM>
In-Reply-To: <41A414D8.5090205@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I also think you should file a JIRA entry.  I would have at least
expected some message in the derby.log.  A discussion would be good
as I don't know what users want in this case.  Should the connection
request:
~    a) fail with a reasonable message back to user
~    b) succeed but with a warning that the restore did not work back to
user
~    c) succeed but with an error in derby.log
~    d) fail but with an error in derby.log
~    e) succeed with no message
a or b seems reasonable, c or d may be easiest to implement, e seems
unreasonable.

The actual code to execute the restore from backup happens in derby at
"boot" time.  And historically it has been hard to get good error
messages back to user when boot fails at such a low level, I am not
sure what happened in this particular case as I did not debug it.


Amit Handa wrote:
| Calvin Smith wrote:
|
|>Oh man, do I feel stupid. I just re-read the manual again and realized
|>that the restore from path is not the directory into which the backup
|>occurred, but the sub-directory that the backup created in that directory.
|>
|>I was doing:
|>
|>connect 'jdbc:derby:myDb;restoreFrom=/mybackupdir';
|>
|>instead of:
|>
|>connect 'jdbc:derby:myDb;restoreFrom=/mybackupdir/myDb';
|>
|>After trying the second form, it works perfectly. Perhaps a better
|>message (indicating success or failure, instead of silence in both
|>cases) would be helpful, but this was a case of PEBCAK
|>(http://www.hyperdictionary.com/computing/pebcak).
|>
|>Thanks again, and I apologize for wasting anybody's time on a silly
|>problem....
|>
|>-calvin
|>
|>p.s. If anybody thinks that the silent response when the backup
|>directory (which contains the backup database directory) exists but the
|>backup database directory doesn't exist is a bug, I'll be happy to file
|>a Jira issue. This is inconsistent with the behavior when the backup
|>database directory does exist but isn't valid, and the user is notified
|>of an error.
|
|
| Calvin,
|
| I think it would be good to file a bug and have a discussion around it,
| since you started the thread.
| We can always close it later, if we[derby-users] feel otherwise.
|
| thanks,
| Amit
|
|
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBpLTsEpeslyHqPs0RAupwAJ42kgH2y+NTyoiFF+RGn/CUr/R5zACeIuql
h1dOehznio9vVNpR2xKoyP0=
=6lch
-----END PGP SIGNATURE-----