db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject Re: [jira] Updated: (DERBY-406) Client DataSource should not require user property to be set
Date Mon, 04 Jul 2005 12:37:58 GMT
Dan Debrunner wrote:

>
>
> Philip Wilder (JIRA) wrote:
>
> >      [ http://issues.apache.org/jira/browse/DERBY-406?page=all ]
> >
> > Philip Wilder updated DERBY-406:
> > --------------------------------
> >
> >     Attachment: Derby406_409_410.patch
> >
> > A Combined patch for DERBY-406, DERBY-409 and DERBY-410
>
> So how is this patch different to the one described early?


Kathey did a good job of summerizing the additional changes made to this 
patch in this reply 
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/%3c42C5A106.5050704@sbcglobal.net%3e



You can ignore her mea culpa comments though, I was the one rushing :-)

> I would disagree with having a default value for password.



Valid disagreement, Kathey was quick to pick up on the same problem. I 
had misread the code and it was a case of trying to make a right out of 
2 wrongs.

> [Philip's earlier description]
> > - Set password to a default value ("defaultpassword")
> > - Set user to default to "APP"
> > - Set the default servername to "localhost"
> > - Changed the updateDataSourceValues of the ClientBaseDataSource 
> class to update the password value if a password is found in the 
> connection attributes.
> > - Changed
> > databaseName_ = dataSource.getDatabaseName() + attrString;
> > to
> > databaseName_ = dataSource.getDatabaseName() + ";" + attrString;
> > in the connection class to avoid database names like myDBcreate=true 
> when the setConnectionAttributes method is used.
> > - Changed the dataSourcePermissions_net to include additional tests 
> to check bug fixes and changed the associated.out file to match new 
> output.
> >
> > Also with regards to the "Client data source published api javadoc 
> cleanup" email sent out by Dan I changed the password, user and 
> servername attributes to private so as to hopefully not conflict with 
> his changes.
>
> Actually, performing such a change yourself is more likely to cause
> conflict. Just focus on your own changes don't try to pre-incorporate
> other changes. :-)
>
Noted for future reference. If you think it is really a problem I can 
attempt to "rollback" my patch to a previous (local) version but I think 
we only have an overlap of about 1/2 dozen lines.

> Dan.


Mime
View raw message