Solution: jdbcclient.jar is always prompting even there is password list in .monetdb
I use jdbcclient.jar to backup several table periodically with my crontab. I already put .monetdb with my password text there. But there is problem, it' s always prompting for password.
I check the source and i make it right with this solution:
before : if (user != equals(copts.getOption("user").getArgument()) pass = null;
after:
if (!user.equals(copts.getOption("user").getArgument())) pass = null;
regards
_______________________________________________ developers-list mailing list developers-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/developers-list
On 09-01-2013 17:24:34 +0800, sigit kartiko wrote:
I use jdbcclient.jar to backup several table periodically with my crontab. I already put .monetdb with my password text there. But there is problem, it' s always prompting for password.
I check the source and i make it right with this solution:
before :
if (user != equals(copts.getOption("user").getArgument()) pass = null;
after:
if (!user.equals(copts.getOption("user").getArgument())) pass = null;
No, this would change the behaviour and crash. user can be null here, when there was no .monetdb file, or user wasn't set in it using: user=youruser
The intended behaviour is that when you specify the user on the command line (-u), you always wipe the password previously read, regardless whether this given user is the same as given in the .monetdb file.
Hence my suspicion is that you supply -u to JdbcClient upon invocation. Simply dropping that should do.
On side note: we strongly advice you to use mclient for dumping instead of JdbcClient. The latter has long been deprecated in favour of the first. mclient's dumping preserves the data better. JdbcClient is not supported, as it's simply a JDBC debugging aid.
But Fabian, in java you cannot compare strings with == or != , it must be .equals() method. In line 145: MonetDB-11.13.7/java/src/nl/cwi/monetdb/client/JdbcClient.java --> user != copts.getOption("user").getArgument()
---------^ this is not ok.
I have no idea to dump a table (not database) with mclient in my MonetDB-11.13.7. That's why i use
this jdbcclient.jar.
Btw, thanks to monetdb, this db rocks..!!!
________________________________ Dari: Fabian Groffen fabian@monetdb.org Kepada: developers-list@monetdb.org Dikirim: Kamis, 10 Januari 2013 15:51 Judul: Re: Solution: jdbcclient.jar is always prompting even there is password list in .monetdb
No, this would change the behaviour and crash. user can be null here, when there was no .monetdb file, or user wasn't set in it using: user=youruser
The intended behaviour is that when you specify the user on the command line (-u), you always wipe the password previously read, regardless whether this given user is the same as given in the .monetdb file.
Hence my suspicion is that you supply -u to JdbcClient upon invocation. Simply dropping that should do.
On side note: we strongly advice you to use mclient for dumping instead of JdbcClient. The latter has long been deprecated in favour of the first. mclient's dumping preserves the data better. JdbcClient is not supported, as it's simply a JDBC debugging aid.
On Fri, Jan 11, 2013 at 01:40:45AM +0800, sigit kartiko wrote:
But Fabian, in java you cannot compare strings with == or != , it must be .equals() method. In line 145: MonetDB-11.13.7/java/src/nl/cwi/monetdb/client/JdbcClient.java --> user != copts.getOption("user").getArgument()
---------^ this is not ok.
I have no idea to dump a table (not database) with mclient in my MonetDB-11.13.7. That's why i use
from `man mclient` and/or http://www.monetdb.org/Documentation/mclient-man-page: " --interactive[=timermode] (-i[timermode]) When reading from standard input, interpret lines starting with \ (backslash) specially. See the section BACKSLASH COMMANDS below. This is the default if standard input is a terminal. The optional timermode argument controls the format of the time reported for queries. Note that no space is allowed between -i and timermode. The default mode is human which adjusts the time precision to the measured value. The modes ms, s and m force millisecond, second and minute + second precision respectively. " and " \D table Dump the given table. "
or from `mclient --help`: " -i | --interactive[=tm] interpret \ commands on stdin, use time formatting {ms,s,m} " and from `echo '?' | mclient -i`: " \D table- dumps the table, or the complete database if none given. "
this jdbcclient.jar.
Btw, thanks to monetdb, this db rocks..!!!
Dari: Fabian Groffen fabian@monetdb.org Kepada: developers-list@monetdb.org Dikirim: Kamis, 10 Januari 2013 15:51 Judul: Re: Solution: jdbcclient.jar is always prompting even there is password list in .monetdb
No, this would change the behaviour and crash. user can be null here, when there was no .monetdb file, or user wasn't set in it using: user=youruser
The intended behaviour is that when you specify the user on the command line (-u), you always wipe the password previously read, regardless whether this given user is the same as given in the .monetdb file.
Hence my suspicion is that you supply -u to JdbcClient upon invocation. Simply dropping that should do.
On side note: we strongly advice you to use mclient for dumping instead of JdbcClient. The latter has long been deprecated in favour of the first. mclient's dumping preserves the data better. JdbcClient is not supported, as it's simply a JDBC debugging aid.
-- Fabian Groffen fabian@monetdb.org column-store pioneer http://www.monetdb.org/Home
developers-list mailing list developers-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/developers-list
developers-list mailing list developers-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/developers-list
On 10-01-2013 20:54:56 +0100, Stefan Manegold wrote:
On Fri, Jan 11, 2013 at 01:40:45AM +0800, sigit kartiko wrote:
But Fabian, in java you cannot compare strings with == or != , it must be .equals() method. In line 145: MonetDB-11.13.7/java/src/nl/cwi/monetdb/client/JdbcClient.java --> user != copts.getOption("user").getArgument()
---------^ this is not ok.
No, look at the comment right above the line. We can, because we're comparing objects here, and the only thing we need to know, is if the initial object has changed into another one (String).
participants (3)
-
Fabian Groffen -
sigit kartiko -
Stefan Manegold