Thread: First test of the Database Designer
Hi,
I tried Luis's repo this morning, and here are the things I've found
that still need some work before reaching the first goal:
* 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
* I should be able to right click on an empty schema to create a table
* What is the "short name" of a table?
* 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)
* UI of relationships
* it should be possible to create relationships between existing
columns
* adding a char(n) type doesn't ask for its length
* 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)
* I can't use the del key when I select an object (table and
relationship)
* 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
* if the user asks for a new design, the sql textbox should be empty too
* 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
* 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
* in a table box, there is a "Indexes" item never used. It should
disappeared.
* I can move a table outside of the drawing area, and I can never get it
back
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). 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.
So, Luis, you need to work on this list of items, and fix them. Once
that's done, I'll get another look at your code.
Thanks.
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com
On Sat, Jun 11, 2011 at 3:06 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote:
Well this error happens when this source code is executed:
wxCmdLineParser cmdParser(cmdLineDesc, argc, argv);
if (cmdParser.Parse() != 0)
return false;
if ((cmdParser.Found(wxT("q")) && cmdParser.Found(wxT("qc"))) ||
(cmdParser.Found(wxT("S")) && cmdParser.Found(wxT("Sc"))) ||
(cmdParser.Found(wxT("d")) && cmdParser.Found(wxT("dc"))))
....
here an assertion is raised, I always got this assert and I just ignored it, because I believe isn't related to my source code and this is probably a side effect from that xiul/gsoc2010 merge with gleu/ticket and the merge with pgadmin3 repo at github, and in fact I don't merge mi repo with original pgadmin3 from start of my coding at gsoc, because that process make me loss a lot of time with conflicts in parts of pgAdmin source code that I didn't modify in any way, in fact my source code is very isolate right now.
Good idea, I don't thought on this because I'm not focused on usability right now, just I want everything works as good as possible with so little time to do many things.
That is part of the automatic fk naming subsystem, I explain here:
Table A [source of fk] ---------< Table B [destination of fk]
- At beginning of fk, all pk or uk column from source table are added to destination table.
- Each of this columns needs a name, an automatic one at the beginning.
- To create this name there are two options:
source table name + _ + original column name
or
source short table name (if exists) + _ + original column name
- But if user choose to use their own name he can do it, and then auto naming subsystem for this column is off, later if he user likes it, he is able to turn it on by right click on that column.
- Constraint name from fk when autonaming is used, is taken from short name too.
In little words this is just a way of helping user to have and good automatic naming convention if he likes to use, but if he doesn't like he just edit column name and constraint name, and auto naming subsystem turn off.
Well again, I'm not focused on usability right now I just wanted everything works fine, but in my testing:
- Focus is on first texbox at least on my development environment.
- Enter at first textbox failed, right, I'll fixed it.
- Right now pressing esc trigger cancel at least on my development environment.
- What should I do with generate short name? change position or delete it?
This is a new feature that requires changing the subsystem of relationship creation, and I didn't do at first goal as I told you at beginning only fixing of old source code and not adding new features, but if you want it I'll be glad of doing it but this probably will affect my proposal schedule and I need your confirmation. Should I do this feature?
I'll fix it.
This list is just as we agree at last year, some important datatypes and list with all when user need more.
What should I modify the list? or How do you believe it should be done?
I'll fix precision of types.
Keyboard shorcuts is a new feature (need modification of framework, and figures is not as easy as adding a new event to some class), I didn't do this as I explain you above. Again, I'll be glad of doing it but this probably will affect my proposal schedule and I need your confirmation. Should I do this feature?
As I explain you right now angle lines don't allow me to have this kind of realtionships and a new kind of lines (orthogonal lines) should be implemented for this reason. Again, I'll be glad of doing it but this probably will affect my proposal schedule and I need your confirmation. Should I do this feature?
I'll fix that.
You're right, index part right now are out of scope but in a future them should be coded.
That's right but only for bottom and right sides, because I would implement a function that auto resize canva if user go in any of this direction, but right now that function was harder to code that I believes and is no implemented, because this I'll disallow moving figures to this sides.
Self foreign key is a new feature that needs orthogonal lines features to be implemented.
I agree with you at this point is not commitable becuase last patch will be the really commitable one, but as you explain me, I'll make this patch commitable.
Regards, Luis.
Hi,
I tried Luis's repo this morning, and here are the things I've found
that still need some work before reaching the first goal:
* 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 this error happens when this source code is executed:
wxCmdLineParser cmdParser(cmdLineDesc, argc, argv);
if (cmdParser.Parse() != 0)
return false;
if ((cmdParser.Found(wxT("q")) && cmdParser.Found(wxT("qc"))) ||
(cmdParser.Found(wxT("S")) && cmdParser.Found(wxT("Sc"))) ||
(cmdParser.Found(wxT("d")) && cmdParser.Found(wxT("dc"))))
....
here an assertion is raised, I always got this assert and I just ignored it, because I believe isn't related to my source code and this is probably a side effect from that xiul/gsoc2010 merge with gleu/ticket and the merge with pgadmin3 repo at github, and in fact I don't merge mi repo with original pgadmin3 from start of my coding at gsoc, because that process make me loss a lot of time with conflicts in parts of pgAdmin source code that I didn't modify in any way, in fact my source code is very isolate right now.
* I should be able to right click on an empty schema to create a table
Good idea, I don't thought on this because I'm not focused on usability right now, just I want everything works as good as possible with so little time to do many things.
* What is the "short name" of a table?
That is part of the automatic fk naming subsystem, I explain here:
Table A [source of fk] ---------< Table B [destination of fk]
- At beginning of fk, all pk or uk column from source table are added to destination table.
- Each of this columns needs a name, an automatic one at the beginning.
- To create this name there are two options:
source table name + _ + original column name
or
source short table name (if exists) + _ + original column name
- But if user choose to use their own name he can do it, and then auto naming subsystem for this column is off, later if he user likes it, he is able to turn it on by right click on that column.
- Constraint name from fk when autonaming is used, is taken from short name too.
In little words this is just a way of helping user to have and good automatic naming convention if he likes to use, but if he doesn't like he just edit column name and constraint name, and auto naming subsystem turn off.
* 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)
Well again, I'm not focused on usability right now I just wanted everything works fine, but in my testing:
- Focus is on first texbox at least on my development environment.
- Enter at first textbox failed, right, I'll fixed it.
- Right now pressing esc trigger cancel at least on my development environment.
- What should I do with generate short name? change position or delete it?
* UI of relationships
* it should be possible to create relationships between existing
columns
This is a new feature that requires changing the subsystem of relationship creation, and I didn't do at first goal as I told you at beginning only fixing of old source code and not adding new features, but if you want it I'll be glad of doing it but this probably will affect my proposal schedule and I need your confirmation. Should I do this feature?
* adding a char(n) type doesn't ask for its length
I'll fix it.
* 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)
This list is just as we agree at last year, some important datatypes and list with all when user need more.
What should I modify the list? or How do you believe it should be done?
I'll fix precision of types.
* I can't use the del key when I select an object (table and
relationship)
Keyboard shorcuts is a new feature (need modification of framework, and figures is not as easy as adding a new event to some class), I didn't do this as I explain you above. Again, I'll be glad of doing it but this probably will affect my proposal schedule and I need your confirmation. Should I do this feature?
* 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
As I explain you right now angle lines don't allow me to have this kind of realtionships and a new kind of lines (orthogonal lines) should be implemented for this reason. Again, I'll be glad of doing it but this probably will affect my proposal schedule and I need your confirmation. Should I do this feature?
* if the user asks for a new design, the sql textbox should be empty too
I'll fix that.
* 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
I'll fix that.
* 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...
I'll implement this.
this way, the user knows quickly which constraint is
used, and could change it quickly... and you have one less dialog
* in a table box, there is a "Indexes" item never used. It should
disappeared.
You're right, index part right now are out of scope but in a future them should be coded.
* I can move a table outside of the drawing area, and I can never get it
back
That's right but only for bottom and right sides, because I would implement a function that auto resize canva if user go in any of this direction, but right now that function was harder to code that I believes and is no implemented, because this I'll disallow moving figures to this sides.
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).
Self foreign key is a new feature that needs orthogonal lines features to be implemented.
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 agree with you at this point is not commitable becuase last patch will be the really commitable one, but as you explain me, I'll make this patch commitable.
So, Luis, you need to work on this list of items, and fix them. Once
that's done, I'll get another look at your code.
Thanks.
Regards, Luis.
On Sat, 2011-06-11 at 12:58 -0430, Luis Ochoa wrote:
> On Sat, Jun 11, 2011 at 3:06 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> Hi,
>
> I tried Luis's repo this morning, and here are the things I've
> found
> that still need some work before reaching the first goal:
>
> * 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 this error happens when this source code is executed:
> wxCmdLineParser cmdParser(cmdLineDesc, argc, argv);
> if (cmdParser.Parse() != 0)
> return false;
>
> if ((cmdParser.Found(wxT("q")) && cmdParser.Found(wxT("qc"))) ||
> (cmdParser.Found(wxT("S")) && cmdParser.Found(wxT("Sc"))) ||
> (cmdParser.Found(wxT("d")) && cmdParser.Found(wxT("dc"))))
> ....
> here an assertion is raised, I always got this assert and I just
> ignored it, because I believe isn't related to my source code and this
> is probably a side effect from that xiul/gsoc2010 merge with
> gleu/ticket and the merge with pgadmin3 repo at github, and in fact I
> don't merge mi repo with original pgadmin3 from start of my coding at
> gsoc, because that process make me loss a lot of time with conflicts
> in parts of pgAdmin source code that I didn't modify in any way, in
> fact my source code is very isolate right now.
>
You can't have it both ways. Either your code is really isolated, and
you shouldn't have conflicts that makes you lose so much time, or you
code isn't.
The assertion is no big deal. But the fact your code is not correctly
merged is big one. This really is a big issue because it means we can't
simply integrate your patch in pgAdmin.
> * I should be able to right click on an empty schema to create
> a table
>
> Good idea, I don't thought on this because I'm not focused on
> usability right now, just I want everything works as good as possible
> with so little time to do many things.
>
Once again, I'm waiting for a complete patch. And without usability, it
can't be commited in the pgadmin repository.
I know you're working on that issue, and that's good. But you need to
keep in mind we've setup a few milestones where we specifically said
that they will be reached once we got a commitable patch. So usability
is important for each milestone.
> * What is the "short name" of a table?
>
> That is part of the automatic fk naming subsystem, I explain here:
>
> Table A [source of fk] ---------< Table B [destination of fk]
>
>
> - At beginning of fk, all pk or uk column from source table are added
> to destination table.
> - Each of this columns needs a name, an automatic one at the
> beginning.
> - To create this name there are two options:
> source table name + _ + original column name
> or
> source short table name (if exists) + _ + original column name
>
> - But if user choose to use their own name he can do it, and then auto
> naming subsystem for this column is off, later if he user likes it, he
> is able to turn it on by right click on that column.
>
> - Constraint name from fk when autonaming is used, is taken from short
> name too.
>
> In little words this is just a way of helping user to have and good
> automatic naming convention if he likes to use, but if he doesn't like
> he just edit column name and constraint name, and auto naming
> subsystem turn off.
>
OK, fine with me.
> * 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)
>
> Well again, I'm not focused on usability right now I just wanted
> everything works fine, but in my testing:
>
> - Focus is on first texbox at least on my development environment.
Not in mine. I can't type the table name right away. I need to click in
the textbox.
> - Enter at first textbox failed, right, I'll fixed it.
Good.
> - Right now pressing esc trigger cancel at least on my development
> environment.
Not in mine.
> - What should I do with generate short name? change position or delete
> it?
>
The former (change position).
> * UI of relationships
> * it should be possible to create relationships between
> existing
> columns
>
> This is a new feature that requires changing the subsystem of
> relationship creation, and I didn't do at first goal as I told you at
> beginning only fixing of old source code and not adding new features,
> but if you want it I'll be glad of doing it but this probably will
> affect my proposal schedule and I need your confirmation. Should I do
> this feature?
>
When are you supposed to do it? if it's already in your planning, that's
fine with me.
> * adding a char(n) type doesn't ask for its length
>
> I'll fix it.
>
Thanks.
> * 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)
>
> This list is just as we agree at last year, some important datatypes
> and list with all when user need more.
Yes, but that's not what happened. I have a list of important data
types, and I can have a dialog with some types. That dialog should
contain all the datatypes available on this server.
> What should I modify the list? or How do you believe it should be
> done?
>
Grabing all the datatypes in the pg_type catalog.
> I'll fix precision of types.
>
Thanks.
> * I can't use the del key when I select an object (table and
> relationship)
>
> Keyboard shorcuts is a new feature (need modification of framework,
> and figures is not as easy as adding a new event to some class), I
> didn't do this as I explain you above. Again, I'll be glad of doing it
> but this probably will affect my proposal schedule and I need your
> confirmation. Should I do this feature?
>
When are you supposed to do it? if it's already in your planning, that's
fine with me.
> * 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
>
> As I explain you right now angle lines don't allow me to have this
> kind of realtionships and a new kind of lines (orthogonal lines)
> should be implemented for this reason. Again, I'll be glad of doing it
> but this probably will affect my proposal schedule and I need your
> confirmation. Should I do this feature?
>
When are you supposed to do it? if it's already in your planning, that's
fine with me.
> * if the user asks for a new design, the sql textbox should be
> empty too
>
> I'll fix that.
>
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
> I'll fix that.
>
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...
> I'll implement this.
>
Thanks.
>
> this way, the user knows quickly which constraint is
> used, and could change it quickly... and you have one less
> dialog
>
> * in a table box, there is a "Indexes" item never used. It
> should
> disappeared.
>
> You're right, index part right now are out of scope but in a future
> them should be coded.
>
Yeah, but they aren't right now. Many things should be implemented, it
doesn't mean they should appear now. That's a confusing UI.
> * I can move a table outside of the drawing area, and I can
> never get it
> back
>
> That's right but only for bottom and right sides, because I would
> implement a function that auto resize canva if user go in any of this
> direction, but right now that function was harder to code that I
> believes and is no implemented, because this I'll disallow moving
> figures to this sides.
>
OK.
>
> 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).
>
> Self foreign key is a new feature that needs orthogonal lines features
> to be implemented.
>
Yes.
> 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 agree with you at this point is not commitable becuase last patch
> will be the really commitable one, but as you explain me, I'll make
> this patch commitable.
>
We can't wait for last patch. If we wait for last patch, it'll be a huge
one, and a lot of work will be needed. I really prefer to move one step
at a time.
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com
On Sat, 2011-06-11 at 09:36 +0200, Guillaume Lelarge wrote: > Hi, > > I tried Luis's repo this morning, and here are the things I've found > that still need some work before reaching the first goal: > > * 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 > > * I should be able to right click on an empty schema to create a table > > * What is the "short name" of a table? > > * 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) > > * UI of relationships > * it should be possible to create relationships between existing > columns > > * adding a char(n) type doesn't ask for its length > > * 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) > > * I can't use the del key when I select an object (table and > relationship) > > * 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 > > * if the user asks for a new design, the sql textbox should be empty too > > * 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 > * 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 > > * in a table box, there is a "Indexes" item never used. It should > disappeared. > > * I can move a table outside of the drawing area, and I can never get it > back > > 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). 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. > > So, Luis, you need to work on this list of items, and fix them. Once > that's done, I'll get another look at your code. > 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). -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
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.
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 should be able to right click on an empty schema to create a table
Done.
* 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.
new UI is:
table name [text] short name [text] [generate button]
[ok button] [cancel button]
* UI of relationships
* it should be possible to create relationships between existing
columns
Right now working on it...
* adding a char(n) type doesn't ask for its length
Fixed for all datatypes, added precision and scale to numeric too.
* 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 ?
* I can't use the del key when I select an object (table and
relationship)
Added.
* 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.
* if the user asks for a new design, the sql textbox should be empty too
Done.
* 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.
* 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.
* in a table box, there is a "Indexes" item never used. It should
disappeared.
Removed.
* I can move a table outside of the drawing area, and I can never get it
back
Fixed.
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?
Regards, Luis.
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
On Sat, 2011-06-25 at 12:18 +0200, Guillaume Lelarge wrote: > [...] > 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. > Branch available here: https://github.com/gleu/pgadmin3/tree/gsoc2011 Patches attached (they will be applied as one). -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
Attachment
On Sat, 2011-06-25 at 15:51 +0200, Guillaume Lelarge wrote: > On Sat, 2011-06-25 at 12:18 +0200, Guillaume Lelarge wrote: > > [...] > > 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. > > > > Branch available here: > > https://github.com/gleu/pgadmin3/tree/gsoc2011 > > Patches attached (they will be applied as one). > And here are the changes on the VC++ project file. Waiting for comments before applying :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
Attachment
On Sat, Jun 25, 2011 at 3:50 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Sat, 2011-06-25 at 15:51 +0200, Guillaume Lelarge wrote: >> On Sat, 2011-06-25 at 12:18 +0200, Guillaume Lelarge wrote: >> > [...] >> > 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. >> > >> >> Branch available here: >> >> https://github.com/gleu/pgadmin3/tree/gsoc2011 >> >> Patches attached (they will be applied as one). >> > > And here are the changes on the VC++ project file. > > Waiting for comments before applying :) Hi, Sorry - in the late stages of my current project, so I'm swamped with testing/QA/docs/you name it! I won't be able to review, but trust you to do so Guillaume. The one comment I would make from the thread is that I don't think the code should be committed without the XRC changes you mention. If that's not done before it's committed, I doubt it ever will be. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Sun, 2011-06-26 at 20:29 +0100, Dave Page wrote: > On Sat, Jun 25, 2011 at 3:50 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > On Sat, 2011-06-25 at 15:51 +0200, Guillaume Lelarge wrote: > >> On Sat, 2011-06-25 at 12:18 +0200, Guillaume Lelarge wrote: > >> > [...] > >> > 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. > >> > > >> > >> Branch available here: > >> > >> https://github.com/gleu/pgadmin3/tree/gsoc2011 > >> > >> Patches attached (they will be applied as one). > >> > > > > And here are the changes on the VC++ project file. > > > > Waiting for comments before applying :) > > Hi, > > Sorry - in the late stages of my current project, so I'm swamped with > testing/QA/docs/you name it! I won't be able to review, but trust you > to do so Guillaume. OK, thanks. > The one comment I would make from the thread is > that I don't think the code should be committed without the XRC > changes you mention. If that's not done before it's committed, I doubt > it ever will be. > I don't want that Luis lost some time working on the XRC files. And I don't want him to get stuck before I do it. So, I commited the patch, and pushed it, so that he could work from the new master. And I'll work on the XRC files tonight. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Mon, 2011-06-27 at 09:09 +0200, Guillaume Lelarge wrote: > On Sun, 2011-06-26 at 20:29 +0100, Dave Page wrote: > > On Sat, Jun 25, 2011 at 3:50 PM, Guillaume Lelarge > > <guillaume@lelarge.info> wrote: > > > On Sat, 2011-06-25 at 15:51 +0200, Guillaume Lelarge wrote: > > >> On Sat, 2011-06-25 at 12:18 +0200, Guillaume Lelarge wrote: > > >> > [...] > > >> > 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. > > >> > > > >> > > >> Branch available here: > > >> > > >> https://github.com/gleu/pgadmin3/tree/gsoc2011 > > >> > > >> Patches attached (they will be applied as one). > > >> > > > > > > And here are the changes on the VC++ project file. > > > > > > Waiting for comments before applying :) > > > > Hi, > > > > Sorry - in the late stages of my current project, so I'm swamped with > > testing/QA/docs/you name it! I won't be able to review, but trust you > > to do so Guillaume. > > OK, thanks. > > > The one comment I would make from the thread is > > that I don't think the code should be committed without the XRC > > changes you mention. If that's not done before it's committed, I doubt > > it ever will be. > > > > I don't want that Luis lost some time working on the XRC files. And I > don't want him to get stuck before I do it. So, I commited the patch, > and pushed it, so that he could work from the new master. And I'll work > on the XRC files tonight. > Done partly. I still have one dialog to work on. But I need more informations from Luis. So, it'll have to wait. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com