Re: Database designer - Mailing list pgadmin-hackers

Hi

On Thu, Mar 1, 2012 at 4:06 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:

>> 2) Why does it take so many steps to add a column? Click the + icon,
>> and choose a name, then right click and select a datatype
>> (incidentally, some common types like "text" require additional steps
>> to select from a dialogue, which still doesn't list things like array
>> types or use the proper names for aliased types we use elsewhere),
>> then right-click again if I need to add constraints, and right click
>> *again* if I then want to rename the constraint.
>
> I agree it would be better to not have all of this. This is something I
> want to work on, but didn't find the time yet. My main idea was to add a
> properties widget to handle the properties of table (and columns).

That's one idea. The main thing is to be able to edit everything in
one place without having to repeatedly right click to change a
different property.

>>  This should all be
>> done using the existing "Add Column" dialogue.
>
> If you mean dlgColumn, I disagree. If you mean enhancing the current
> dialog of DD, yeah why not. But I would rather much have a properties
> widget to avoid the use of a dialog.

I'd be OK with a suitable properties widget - certainly if we used the
dialogue some elements would need to be hidden/disabled... but, if we
use a dialogue to put everything in one place, it makes sense to use
the same design we already have as it aids user experience by
presenting them with a consistent, familiar interface.

>>  Similarly, the Tables
>> properties dialogue should probably also be used to edit entire
>> tables.
>>
>
> Not sure what you mean here.

To edit table-level stuff (name etc), we should also use the existing
dialogue. Or a properties pane. Again, for consistency.

>> 4) Columns and tables have "default" names when you create them, which
>> is inconsistent with the rest of the application.
>>
>
> If the "rest of the application" is the browser, well, the DD is another
> tool and may require any behaviour. But we can get rid of the
> autonaming, I have no issue with that. BTW, we already use autonaming
> for the autoindex of an FK.

DD is part of the same product, and should be consistent in design
with the rest of the product. I consider the autoindex name to be a
little different - a) it's something users normally won't want to
change, and b) it's based on the name they did enter themselves - it's
not a meaningless default.

OK, let me rephrase. Why am I asked for one? What effect does it have
on the generated schema?

>> 8) Why do I have to select a table before I can add a column to it for
>> the first time, but to modify it (except to add a relationship) I can
>> right-click and existing column? Seems partially related to 6).
>>
>
> Not sure why Luis did it that way. The advantage I see is that I don't
> need to have multiple levels of dialogs.

I can't see that it would require any difference in dialogues. I'd
still need to name the column, but otherwise it just requires me to
add the first column in one way (by clicking the table), while
subsequent ones can be added in the same way, or by right clicking.
Why can't I just right-click for them all?

>> 11) Somehow, I managed to "minimise" a table, so that only the primary
>> key column is shown. I have no idea how. Clicking on what now looks
>> like a maximise icon that's appeared doesn't fix it (though the icon
>> does change to what looks like a minimise icon). The relationship
>> lines still render as if the table was the original size, even if I
>> move a table to force it to redraw.
>>
>
> I didn't remember we could minimise/maximise tables, but seems a good
> idea anyway. Need to fix the bug though.

It does seem reasonable, yes - especially for wide tables with lots of
columns. It should be more obvious how I did it though (or how to do
it).

>> 13) There is a "Preferences" menu. Why isn't the existing Option dialogue used?
>>
>
> Because it was easier for Luis to do it this way, and finish his project
> on time. I failed to find time to fix this, even if it's something I
> want to do.

Hmm, AKA: not ready to commit!

>> All in all, I'm pretty disappointed. As it stands, this feature seems
>> to need a lot of work to get it to a standard that I'd be happy to see
>> in 1.16 :-(
>>
>
> Yes, it still needs some work. Most of your complaints are valid, and
> are known at least to me. I wanted to work on them earlier, but failed
> to find the time to fix them. Anyway, most of them aren't difficult.

Good :-)

> Kinda funny that, at the same time you sent your email, I had Luis on IM
> telling me he wanted to continue his work on the database designer.

Also good - we need to get this sorted out prior to release to avoid
having to remove such a valuable feature.