Re: First test of the Database Designer

Sorry for not being able to answer you before, I was without internet
connection most of this week.

On Thu, 2011-06-16 at 17:57 -0430, Luis Ochoa wrote:
> Can you tell me how much progress you did since you started
> working on
> this list? I tried to compile your branch tonight, but got
> some errors
> about missing files. Should be the same issue as always
> (obsolete
> module.mk files).
>
>
>
>
>
>

> I just made a git pull from my repository at latest
> commit: 985002d4eff2d42d1d6b then made a git diff looking for local
> difference and any diff weren't located. then I emit a bash bootstrap,
> later a configure, and at last a make at my ubuntu 11.04 machine.
>
>
> Then everything goes fine and no errors where raised.
>
>
> I'm not sure about what's your problem but I can tell you that after
> all previous errors, I had tried to avoid obsoletes module.mk files at
> my commits.
>

OK. I tried this morning and it went fine.

> Now information about all TODOs from mentor
>
> * I have an assertion each time I launch pgAdmin2 from your
> repo:
> Debug: ./src/common/cmdline.cpp(446): assert "i != (-1)"
> failed in
> Found(): unknown switch
>
>
> Well, I'm not sure how to solve this error because this probably is a
> merging problem of gleu repo with my pgadmin3 fork and original
> pgadmin3 at github of a part of pgAdmin that I don't know how works,
> and I have never modified, because that have raised like 100+ hundreds
> conflicts and I tried to solve as good as my knowledge of pgAdmin let
> me to do it.
>

I merged your work on my ticket225 branch, and it worked great, with no
assertions.

BTW, I also created the complete patch (gsoc2010 plus your new work). It
applies mostly cleanly. The big issue is we abandonned .xpm files
for .png files. There are some work to do there, work I'll do when I'll
commit the patch.

> * I should be able to right click on an empty schema to create
> a table
>
>
> Done.
>

Works great.

> * UI of new table dialog:
> * the "Generate Short Name" button should not be there
> * focus should be on the first textbox
> * OK should be the default button (iow, hitting enter should
> trigger
> it)
> * Cancel should behave like any cancel button (iow, hitting
> esc should
> trigger it)
>
>
> show dialog -> focus at first textbox, enter at that textbox will be
> the same as click over ok button.
> pressing esc-> will be the same as click over cancel button.
>
>

Works great.

> new UI is:
>
>
> table name [text] short name [text] [generate button]
> [ok button] [cancel button]
>

Yeah, I don't really like that, and I don't really like the way you draw
the dialog. I would much prefer the use of a .xrc file. But this is
something I can do later, not something you should care now.

>
> * UI of relationships
> * it should be possible to create relationships between
> existing
> columns
>
>
> Right now working on it...
>

You did it this week, and it works great. Once again, the UI is not
really good but I can take care of it later.

> * adding a char(n) type doesn't ask for its length
>
>
> Fixed for all datatypes, added precision and scale to numeric too.
>

Yes, works great.

> * moreover, the list of datatype seems weird to me... you
> should list
> all available types and when the user choose a type with a
> length
> and/or a precision, it should ask them (it's already like
> that for
> varchar, but not for char, numeric, etc)
>
>
> Well, mentor suggestion was grabing all the datatypes in the pg_type
> catalog, but this isn't only getting all datatypes of pg_type it
> include changing the way datatypes are managed right now, and probably
> should be changed at next step of my project of adding support of user
> defined datatypes and because this I believe this is part of that
> project goal. But I'm going to do whatever my mentor suggest me. What
> should I do ?
>

Doing later is not an issue.

> * I can't use the del key when I select an object (table and
> relationship)
>
>
> Added.
>

And tested, works great.

>
> * if I create a relationship between t1 and t2, and then
> between t2 and
> t1, once you start moving one of these tables, the two
> relationships
> appear as just one
>
>
> This is part of a new feature that will change base relationship
> classes. This wasn't planned for this project of improvement of
> database designer, but again if my mentor suggest it, I'll do it.
>

Well, I wish you would do this. But not for patch #1.

>
> * if the user asks for a new design, the sql textbox should be
> empty too
>
>
> Done.
>

OK.

> * UI of relationship contextual menu
> * you should only keep one item of "1:1" and "1:M", it's one
> or the
> other, so you must not offer both with a checkbox
> Done.
>

OK.

> * rather than menu items "Foreign Key from Primary Key", and
> "Foreign
> Key from Unique Key", you should have a sub menu entitled
> "Foreign
> Key From", and, for the items in the submenu, you should
> have
> "Primary Key", and "Unique Constraint "+name of each unique
> constraint... this way, the user knows quickly which
> constraint is
> used, and could change it quickly... and you have one less
> dialog
>
>
> Done.
>

Checked.

>
> * in a table box, there is a "Indexes" item never used. It
> should
> disappeared.
>
>
> Removed.
>

Checked.

>
> * I can move a table outside of the drawing area, and I can
> never get it
> back
>
>
> Fixed.
>

Thanks. That one bothers me, really :)

>
> Even if it's a long list of complaints, I didn't really hit a
> bug like I
> did in the previous GSoC, so that's quite good. I could even
> draw my
> test schema almost completely (almost because Luis's repo
> doesn't
> support yet self referencing table).
>
>
> Related to: two relationships appear as just one.
>
>
> Self referencing table are part of a new feature that will change base
> relationship classes too, and adding it will require to add orthogonal
> lines and new kind of locators of images boundaries and new kind of
> connector. This wasn't planned for this project of improvement of
> database designer, but again if my mentor suggest it, I'll do it. But
> this feature will take like 2 or 1 week in the best case scenary.
>
> That test schema always ended with
> a crash of pgAdmin. That doesn't happen any more, and it's
> good. But
> it's not good enough to be commitable.
>
>
>
>
> I'm going to finish Fk Mapping Subsystem between today and tomorrow,
> and I will end all except this two new features:
>
>
> - self relationships and two relationships appear as just one.
> - datatypes from pg_type catalog.
>
>
> Right now I want to know what should I do with this new features?
>

So, right now, we have something nearly commitable. I still have to fix
the xpm files, and the code using them. It shouldn't be long. Once done,
you'll be able to grab the new master trunk, and work from that. Meaning
we're done with the first milestone at a time where we should be done
with the second one. It isn't a big issue to me. We'll probably have to
drop some features along the way, but that doesn't mean your GSoC
project will fail.

You should start working on your second and third milestones, perhaps
not views and user types, but the overview panel and the personalization
of objects' drawing which are more important features. Color regions
would be good too.

Actually, I don't see what you can do with views. And I don't understand
how I could forget to talk to you about schemas (the SQL object). Can we
add this too? I know it wasn't planned, but it seems important to have
it.

Dave, any objection on applying the current work of Luis? I'll work this
afternoon on the xpm files, I should be able to send a patch after that.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com