Password can't be cleared, once entered into "Favorites"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new database connection to a database which requires no
password, and add it to Favorites before testing it
2. Connect to it, and Fail due to the presence of a password 
3. Delete the Favorite and recreate with no password.  When added to
favorites a password appears

What is the expected output? What do you see instead?
I expect the connection to be totally deleted, yet the Password persists

What version of the product are you using? On what operating system?
v0.9.2

Please provide any additional information below.

Original issue reported on code.google.com by mainstre...@gmail.com on 24 Nov 2008 at 10:24

[GoogleCodeExporter]

The problem here seems to be that Sequel Pro uses the remove: method of the
NSArrayController (Favorites) which will just remove the favorite from the 
array, but
keep the Keychain Item.
The removeFavorite: method from MainController provides a solution that just 
has to
be adapted to the ArrayController.

Original comment by schlabbe...@gmail.com on 25 Nov 2008 at 2:24

[GoogleCodeExporter]

Original comment by stuart02 on 28 Nov 2008 at 1:07

• Added labels: Component-UI, Milestone-Release1.0, Type-Defect

[GoogleCodeExporter]

Original comment by stuart02 on 30 Nov 2008 at 2:14

• Changed state: Accepted
• Added labels: Priority-High

[GoogleCodeExporter]

schlabberdog is right, the favorite is simply being removed from the array 
controller and the Keychain password 
being left behind. I am currently working on resolving some other Keychain 
issues and will also address this 
issue. I think the simplest solution for just now (which I have already 
implemented) is to make the remove 
favorite button on the connection sheet call a removeFavorite: method on the 
TableDocument instance, which 
first removes the Keychain password and then calls the remove: method of the 
array controller. I'll be committing the code later on today.

Original comment by stuart02 on 2 Dec 2008 at 5:31

[GoogleCodeExporter]

A related idea I was going to suggest (and may have, but i can't find it 
anymore) is
to treat connections as documents, rather than instances in a plist.  If the
connection info were stored in SQLP documents, then they can be shared and
source-controlled.  Additional information, such as the fav-query list could 
also
live in these documents, giving the ability to have favorite queries be
database-specific.  And finally, opening the document immediately gets you 
connected
and working on your database, since it would likely remember your last state.  
And
being docs, it means you can connect to your databases via Quicksilver.

I probably should have created a bug for this, and you guys could prioritize it 
as such.

Original comment by mainstre...@gmail.com on 2 Dec 2008 at 5:37

[GoogleCodeExporter]

mainstreetmark, feel free to create an enhancement request for this as it 
definitely sounds like something we 
should be looking into, to increase compatibility with other applications.

Thanks

Original comment by stuart02 on 2 Dec 2008 at 5:41

[GoogleCodeExporter]

This issue is resolved as of r214 as per my solution outlined in my previous 
comment.

Original comment by stuart02 on 2 Dec 2008 at 6:13

• Changed state: Fixed