Re: GSoC database modeler [Luis Ochoa]

On Mon, Aug 16, 2010 at 5:26 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info>wrote:

> Le 16/08/2010 22:40, Thom Brown a écrit :
> > On 16 August 2010 21:05, Luis Ochoa <ziul1979(at)gmail(dot)com> wrote:
> >> Hi, this is my patch for GSoC 2010 database designer for pgAdmin, I hope
> it
> >> likes you, I have done a lot of work to create this modeler, but even
> with
> >> all that work, is unfinished and lacks of a lot of things, but I believe
> >> that it will be ready in a professional way in a few months.
> >>
> >> This is a patch for the git repository, it have been tested at windows
> &
> >> linux.
> >>
> >> you can watch in action (windows) here:
> >>
> >> http://www.youtube.com/watch?v=RbXIuyTIpJ0
> >>
> >> Regards, Luis.
> >>
> >
> > Hi Luis,
> >
> > Nice progress. :) I notice that if you create a new table and then
> > create a foreign key on it from another table, the datatype on the new
> > table is undefined. Couldn't that default to the same datatype as the
> > primary key? (but obviously if the PK is serial/bigserial then it uses
> > int/bigint)
> >
>

In fact that's normal behavior but I changed a last minute first datatype to
serial and I'll check what happened ( a bug sorry :( ), Fk is from same
type as pk and you can't change for obvious reasons (except for special kind
like serial for bigint).

> I think we need to get rid of the "undefined" pseudo-type. I would like
> to change the "Add column" menu item to show a dialog with a text box to
> enter the name of the column and a combobox to choose the type (and
> precision too in case of varchar and numeric type).
>

I believe it too "undefined" should go away, and we can use a default
datatype for column if user wants to change just select another...

Add column at table can bring a dialog, I think to do that but for time
reasons I didn't do it.

> > I still think one thing which definitely needs changing are the
> > controls. Most of them cover a very small pixel area and as such make
> > it tricky to click on and prone to missing them (or at least it would
> > be for me).
>
>
It is just a initial UI design it can be changed, but you always have two
options to do that:

fast-> graphically
normal->contextual menus

> Well, I also think we should get rid of them. Every action should start
> within the contextual menu. No Add or Delete button. And I don't really
> like the "double click" to rename an object. We should use the
> contextual menu once again
>

I really don't support this idea, because I use modelers all the time and
the main idea of why I like to create a new one was:

I like to do modeling as fast as I can, but bringing a window for every
action puts everything slower (with little changes when modeling), but when
you are entering columns at first time I believe a dialog with grid style
will be better (I thought to do that but for time reasons again)

My idea is two ways of entering data to models: graphically & using
properties like dialogs, people must choice what to use in what moment.

> Although I appreciate you're still in the middle of
> > working on everything and are just working on functionality rather
> > than presentation.
>
> Actually, it's the end of the GSoC. I think Luis still wants to work on
> it, and I really hope so.
>
>
UI is just for showing base classes for drawing and modeling working, not a
real window for modeler, it should be changed :D

> > Also, could the play button (which currently shows the SQL) just say
> > "SQL" on it?
>
> Yes, that would be best. The "play" button is the execute button on the
> Query Tool. Quite confusing.
>
> > And for it to appear in a separate panel in the same window?
>

This is really a sandbox for modeler, just like a test of base classes of
the modeler and graphical library, because this gsoc project created two
things:

- A graphical framework for doing modeler and drawing like applications.
-The modeler using the generic framework for graphics.

Real one UI should come later.

We'll probably have to get rid of the notebook and have two panes, one
> to draw the schema, one to see the SQL. They can both have a toolbar. On
> the draw pane, we could have load, save, sql buttons. On the SQL pane,
> we could have save, run, open query tool.
>
>
My idea is one pane for every model, we can open one or more at same time.
SQL can be show in other way...

> > Sort of like results currently do for the SQL Query Editor in
> > PgAdmin. In fact, maybe if the pane is open and you make changes to
> > the diagram, it could update the pane contents in real time?
> >
>
>
Just a test, that notepad is just to show results and must be changed at
real one ;)

> Yeah, could be possible.
>
> The last item we should not forget is a reverse engineer button. I've
> read some parts of the code Luis wrote, and I think it should be pretty
> easy to do. AFAICT, it's a one day job, considering all the foundations
> built by Luis.
>
>
It shouldn't be harder to do it, but there is a lot of things and bugs to
fix before it can be profesionally used.

Regards, Luis.