Thread: Patch for "Panel for Joins in the Graphic Query Builder"
Hi All,
As per my discussion with Dave Page:
- Replace the generic dialog box that the graphical query builder uses when
you right-click a join, and select the join type option. It currently uses
an ugly standard dialog. Create a more compact and purpose built one - like
the one you get when you add criteria, and click on the 'restricted value'
button.
Modifications and addition are as follows:
* Introduced couple of new classes for handling operations:
+ gqbJoinsPanel - Panel for handling the joins in the tab - container for
criteria, order & columns panels
+ gqbJoinsPopUp - Pop up window, when selecting a column from the table list,
derived from the gqbColsPopUp
+ gqbGridJoinTable - Table for handling all the joins data. It handles three
columns Source, Join-Type & Destination
* Added new images gqbAdd.xpm & gqbRemove.xpm
* Renamed wxRestrictionGrid to gqbCustomGrid as we're using the same Grid for
handling the criteria(s) and join(s) in the gqbCriteriaPanel and gqbJoinsPanel
respectively.
* Added one operator [] in gqbArrayCollection for accessing the gqbObject object
directory (replacement/accessibility of the object at particular index will be
easy and fast).
* Removed the context menu "Set Type" removed for join, as this operation will be
handled from the joins-panel now onwards.
Regards,
Ashesh Vashi
As per my discussion with Dave Page:
- Replace the generic dialog box that the graphical query builder uses when
you right-click a join, and select the join type option. It currently uses
an ugly standard dialog. Create a more compact and purpose built one - like
the one you get when you add criteria, and click on the 'restricted value'
button.
Modifications and addition are as follows:
* Introduced couple of new classes for handling operations:
+ gqbJoinsPanel - Panel for handling the joins in the tab - container for
criteria, order & columns panels
+ gqbJoinsPopUp - Pop up window, when selecting a column from the table list,
derived from the gqbColsPopUp
+ gqbGridJoinTable - Table for handling all the joins data. It handles three
columns Source, Join-Type & Destination
* Added new images gqbAdd.xpm & gqbRemove.xpm
* Renamed wxRestrictionGrid to gqbCustomGrid as we're using the same Grid for
handling the criteria(s) and join(s) in the gqbCriteriaPanel and gqbJoinsPanel
respectively.
* Added one operator [] in gqbArrayCollection for accessing the gqbObject object
directory (replacement/accessibility of the object at particular index will be
easy and fast).
* Removed the context menu "Set Type" removed for join, as this operation will be
handled from the joins-panel now onwards.
Regards,
Ashesh Vashi
Hi Ashesh On Mon, Dec 1, 2008 at 10:41 AM, Ashesh D Vashi <ashesh.vashi@enterprisedb.com> wrote: > Modifications and addition are as follows: > * Introduced couple of new classes for handling operations: > + gqbJoinsPanel - Panel for handling the joins in the tab - container for > criteria, order & columns panels > + gqbJoinsPopUp - Pop up window, when selecting a column from the table > list, > derived from the gqbColsPopUp > + gqbGridJoinTable - Table for handling all the joins data. It handles > three > columns Source, Join-Type & Destination > * Added new images gqbAdd.xpm & gqbRemove.xpm > * Renamed wxRestrictionGrid to gqbCustomGrid as we're using the same Grid > for > handling the criteria(s) and join(s) in the gqbCriteriaPanel and > gqbJoinsPanel > respectively. > * Added one operator [] in gqbArrayCollection for accessing the gqbObject > object > directory (replacement/accessibility of the object at particular index > will be > easy and fast). > * Removed the context menu "Set Type" removed for join, as this operation > will be > handled from the joins-panel now onwards. Wow - that's a whole lot more code than I was expecting (and explains why it took somewhat longer than I planned). What I meant, was that I just wanted a replacement dialogue for the existing one. What you've done is reimplement the join handling, in what I think is a *much* nicer way :-) The only issues I've seen while testing (on Windows), are: - The Join label doesn't update on the diagram if you change the join type unless you click on the drawing canvas afterwards. - Selecting a join should select the corresponding row in the list. - You are missing updates to include/images/module.mk and include/gqb/module.mk. The images should also be added to the VC++ project file. Nice work! -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Hi Dave Page,
Please find the updated patch.
Only issue, I can see with the combobox within the Grid, is until you loose the focus
(by either pressing return or moving to other cell), the value is not getting updated
for that particular join
Now onwards,
* For single left click, row will be selected, but the "joins panel" will be activate.
* For double left click, "Joins panel" will be selected and the corresponding row in
the list too.
Thanks & Regards,
Ashesh Vashi
Please find the updated patch.
ThanksWow - that's a whole lot more code than I was expecting (and explains
why it took somewhat longer than I planned). What I meant, was that I
just wanted a replacement dialogue for the existing one. What you've
done is reimplement the join handling, in what I think is a *much*
nicer way :-)
Done
The only issues I've seen while testing (on Windows), are:
- The Join label doesn't update on the diagram if you change the join
type unless you click on the drawing canvas afterwards.
Only issue, I can see with the combobox within the Grid, is until you loose the focus
(by either pressing return or moving to other cell), the value is not getting updated
for that particular join
In fact, I implemented this feature on double click.
- Selecting a join should select the corresponding row in the list.
Now onwards,
* For single left click, row will be selected, but the "joins panel" will be activate.
* For double left click, "Joins panel" will be selected and the corresponding row in
the list too.
Done
- You are missing updates to include/images/module.mk and
include/gqb/module.mk. The images should also be added to the VC++
project file.
Thanks & Regards,
Ashesh Vashi
Oops..
Missed to attach the patch.
Regards,
Ashesh
--
With Regards,
Ashesh Vashi
Software Engineer
EnterpriseDB
(www.enterprisedb.com)
Missed to attach the patch.
Regards,
Ashesh
On Tue, Dec 2, 2008 at 1:32 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dave Page,
Please find the updated patch.ThanksWow - that's a whole lot more code than I was expecting (and explains
why it took somewhat longer than I planned). What I meant, was that I
just wanted a replacement dialogue for the existing one. What you've
done is reimplement the join handling, in what I think is a *much*
nicer way :-)Done
The only issues I've seen while testing (on Windows), are:
- The Join label doesn't update on the diagram if you change the join
type unless you click on the drawing canvas afterwards.
Only issue, I can see with the combobox within the Grid, is until you loose the focus
(by either pressing return or moving to other cell), the value is not getting updated
for that particular joinIn fact, I implemented this feature on double click.
- Selecting a join should select the corresponding row in the list.
Now onwards,
* For single left click, row will be selected, but the "joins panel" will be activate.
* For double left click, "Joins panel" will be selected and the corresponding row in
the list too.Done
- You are missing updates to include/images/module.mk and
include/gqb/module.mk. The images should also be added to the VC++
project file.
Thanks & Regards,
Ashesh Vashi
--
With Regards,
Ashesh Vashi
Software Engineer
EnterpriseDB
(www.enterprisedb.com)
Attachment
Hi, On Tue, Dec 2, 2008 at 8:02 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote: > - The Join label doesn't update on the diagram if you change the join > type unless you click on the drawing canvas afterwards. > > Done > Only issue, I can see with the combobox within the Grid, is until you loose > the focus > (by either pressing return or moving to other cell), the value is not > getting updated > for that particular join I don't see any difference on Windows - I still need to click on the canvas before the label changes. Changing to a difference cell, or hitting return doesn't help. > - Selecting a join should select the corresponding row in the list. > > In fact, I implemented this feature on double click. > Now onwards, > * For single left click, row will be selected, but the "joins panel" will be > activate. > * For double left click, "Joins panel" will be selected and the > corresponding row in > the list too. That sounds good. It seems to work for a while, and then the row highlighting stops working. It seemed to stop after I clicked on (but didn't change the value) in one of the combos in the Join Type column. To get it to work again, I have to close and re-open the query tool. I spotted another minor issue - if I'm on the Joins tab, and I click the Columns tab - the main tab set at the top switches to SQL Editor! -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Dec 1, 2008 at 6:41 AM, Ashesh D Vashi <ashesh.vashi@enterprisedb.com> wrote:
Good improvement, yeah it was my foul :(
Good add-on
Good change, I notice this item probably will be use in the future for others panels but at that moment I hadn't enough time to think in a good name ;)
A good way to access the vector, but allowing the code to access directly the objects based on the index probably decrease the independece of the subyacent structured inside the collection. If I decided to change the vector for a hash map in a future this operator probably difficult the change by example, because now we have hard code access directly to the structure inside the collection.
I'm not really sure about remove the Set type from context menu, because this was the fastest way to do this task, I think it can be change but for a faster one way (like click on the type =,<,> etc and change in a circular way the type), and consequence of forcing the user to use a panel to change some properties in a diagram probably is it can hurt usability.
About Last Dave commentaries:
I fixed this in a very rudimentary way this you can try to find a new and more elegant one solution Ashesh. I included the patch here
the only change was made on gqbGridJoinTable class and affected ones).
About the the two patches:
I have something to tell about the patches: I tried the second patch first but doesn't works, tried the first and works Revert svn and apply second patch and works, there is any file missing in the second patch?
Regards, Luis.
Hi All,
As per my discussion with Dave Page:
- Replace the generic dialog box that the graphical query builder uses when
you right-click a join, and select the join type option. It currently uses
an ugly standard dialog. Create a more compact and purpose built one - like
the one you get when you add criteria, and click on the 'restricted value'
button.
Good improvement, yeah it was my foul :(
Modifications and addition are as follows:
* Introduced couple of new classes for handling operations:
+ gqbJoinsPanel - Panel for handling the joins in the tab - container for
criteria, order & columns panels
Good add-on
+ gqbJoinsPopUp - Pop up window, when selecting a column from the table list,
derived from the gqbColsPopUp
+ gqbGridJoinTable - Table for handling all the joins data. It handles three
columns Source, Join-Type & Destination
* Added new images gqbAdd.xpm & gqbRemove.xpm
* Renamed wxRestrictionGrid to gqbCustomGrid as we're using the same Grid for
handling the criteria(s) and join(s) in the gqbCriteriaPanel and gqbJoinsPanel
respectively.
Good change, I notice this item probably will be use in the future for others panels but at that moment I hadn't enough time to think in a good name ;)
* Added one operator [] in gqbArrayCollection for accessing the gqbObject object
directory (replacement/accessibility of the object at particular index will be
easy and fast).
A good way to access the vector, but allowing the code to access directly the objects based on the index probably decrease the independece of the subyacent structured inside the collection. If I decided to change the vector for a hash map in a future this operator probably difficult the change by example, because now we have hard code access directly to the structure inside the collection.
* Removed the context menu "Set Type" removed for join, as this operation will be
handled from the joins-panel now onwards.
I'm not really sure about remove the Set type from context menu, because this was the fastest way to do this task, I think it can be change but for a faster one way (like click on the type =,<,> etc and change in a circular way the type), and consequence of forcing the user to use a panel to change some properties in a diagram probably is it can hurt usability.
Regards,
Ashesh Vashi
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
About Last Dave commentaries:
I don't see any difference on Windows - I still need to click on the
canvas before the label changes. Changing to a difference cell, or
hitting return doesn't help.
I fixed this in a very rudimentary way this you can try to find a new and more elegant one solution Ashesh. I included the patch here
the only change was made on gqbGridJoinTable class and affected ones).
About the the two patches:
I have something to tell about the patches: I tried the second patch first but doesn't works, tried the first and works Revert svn and apply second patch and works, there is any file missing in the second patch?
Regards, Luis.
Attachment
Hi Luis Ochoa, Thanks for reviewing it. > > A good way to access the vector, but allowing the code to access > directly the objects based on the index probably decrease the > independece of the subyacent structured inside the collection. If I > decided to change the vector for a hash map in a future this operator > probably difficult the change by example, because now we have hard > code access directly to the structure inside the collection. For the same reason, I have not introduced the operator [] in gqbCollection class, but in gqbArrayCollection. I thought - as we are able to access & insert the objects using index. Then, why not to have direct access to the object (easy for replacement too). In case if one of us decide to change the vector for a hash map in a future, the insertion of an object at a particular index will also create the same problem, which this operator will do. What do you say? Sorry if I misunderstood. And thanks for the help. Thanks & Regards, Ashesh
Hi,
Please find the updated patch.
If I make any changes in the "Criteria Panel", and then click "Columns Panel", the main
tab set at the top switches to "SQL Editor". :(
I will send a patch for it.
Thanks Luis for your help.
Your changes are also included in this patch.
Regards,
Ashesh
Please find the updated patch.
Done.- The Join label doesn't update on the diagram if you change the join type unless you click on the drawing canvas afterwards. Done Only issue, I can see with the combobox within the Grid, is until you loose the focus (by either pressing return or moving to other cell), the value is not getting updated for that particular joinI don't see any difference on Windows - I still need to click on the canvas before the label changes. Changing to a difference cell, or hitting return doesn't help.
I think - this is a bug from a while, I can reproduce the same for the "Criteria Panel".I spotted another minor issue - if I'm on the Joins tab, and I click the Columns tab - the main tab set at the top switches to SQL Editor!
If I make any changes in the "Criteria Panel", and then click "Columns Panel", the main
tab set at the top switches to "SQL Editor". :(
I will send a patch for it.
Thanks Luis for your help.
Your changes are also included in this patch.
Regards,
Ashesh
Hi Ashesh On Wed, Dec 3, 2008 at 10:42 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote: > I don't see any difference on Windows - I still need to click on the > canvas before the label changes. Changing to a difference cell, or > hitting return doesn't help. > > > Done. Yup - that looks good now. > That sounds good. It seems to work for a while, and then the row > highlighting stops working. It seemed to stop after I clicked on (but > didn't change the value) in one of the combos in the Join Type column. > To get it to work again, I have to close and re-open the query tool. That is still broken however. Basically, clicking on a join just stops highlighting the appropriate row. Double-clicking doesn't highlight either, but it does still change the tab. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Hi,
Please find the updated patch.
Regards,
Ashesh
Please find the updated patch.
This was happening, because I completely missed to call the gqbCustomGrid's Revert function.That sounds good. It seems to work for a while, and then the row highlighting stops working. It seemed to stop after I clicked on (but didn't change the value) in one of the combos in the Join Type column. To get it to work again, I have to close and re-open the query tool.That is still broken however. Basically, clicking on a join just stops highlighting the appropriate row. Double-clicking doesn't highlight either, but it does still change the tab.
Regards,
Ashesh
On Thu, Dec 4, 2008 at 10:21 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote: > Hi, > > Please find the updated patch. > ... > This was happening, because I completely missed to call the gqbCustomGrid's > Revert function. Thanks - patch applied :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Wed, Dec 3, 2008 at 6:13 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Luis Ochoa,
Thanks for reviewing it.For the same reason, I have not introduced the operator [] in gqbCollection class, but in gqbArrayCollection.
A good way to access the vector, but allowing the code to access directly the objects based on the index probably decrease the independece of the subyacent structured inside the collection. If I decided to change the vector for a hash map in a future this operator probably difficult the change by example, because now we have hard code access directly to the structure inside the collection.
I thought - as we are able to access & insert the objects using index. Then, why not to have direct access to the object (easy for replacement too).
In case if one of us decide to change the vector for a hash map in a future, the insertion of an object at a particular index will also create the same problem, which this operator will do.
What do you say?
Ok no problem I musunderstand all, because I get confused at the moment of that commentary, you're right.
Sorry if I misunderstood.
And thanks for the help.
Thanks & Regards,
Ashesh
As I have told you, this was a bug introduced earlier.
The object sqlNoteBook (in frmQuery class) and the object tabs (in the gqbController class)
both were using the same id (CTL_NTBKCENTER).
And in frmQuery class, an event handler - OnChangeNotebook is registered with this id.
I changed the id for the object tabs of gqbController to CTL_NTBKPANELS.
Please find the patch for the same.
Regards,
Ashesh
Ok a legacy error from the very first beta versions ;) but now is solve. Thanks Ashesh.
By the way Ashesh as I notice you know the tool I'm going to make you some commentaries:
I have been thinking a way of adding the group by and having operators to the GQB to basically allow the user to create more complex queries, but I'm not sure about the correct user interface to do this task, I think that group by can be as the ordering tab and the having tab can be as the criteria tab. Do you have any suggestions?
And about the join panel as I told you I was thinking that if the user select one join should be an easy option to change the query type like a floating toolbar with button with the join types that will be show near the selected join. What do you think about this?
Now I publish a list of what I think will be useful functionalities on the GQB if someone desiree to contribute:
1. Add Subqueries, this probably requeries multiples tabs for query.
2. Add Support to composite types.
3. Add a new skin for the graphics probably with a scroll on right and showing always all the columns (fixed at top) but the other columns can be move up/down with the scrollbar (an option can allow to choose between this and old graphics). And each table have a minimize (shrink only to table title),restore and remove from query button just as a window in a graphical operative system.
4. Add Save/Load functionality (probably xml).
Sorry for a lot of commentaries for just one email.
Finally I tested your patch and everything was fine for me.
Regards, Luis.
Luis Ochoa a écrit : > On Wed, Dec 3, 2008 at 6:13 AM, Ashesh Vashi > <ashesh.vashi@enterprisedb.com <mailto:ashesh.vashi@enterprisedb.com>> > wrote: > > (...) > Now I publish a list of what I think will be useful functionalities on > the GQB if someone desiree to contribute: > 1. Add Subqueries, this probably requeries multiples tabs for query. > 2. Add Support to composite types. > 3. Add a new skin for the graphics probably with a scroll on right and > showing always all the columns (fixed at top) but the other columns can > be move up/down with the scrollbar (an option can allow to choose > between this and old graphics). And each table have a minimize (shrink > only to table title),restore and remove from query button just as a > window in a graphical operative system. > 4. Add Save/Load functionality (probably xml). > Ashesh and Luis, Sorry for not being available to test and comment, I'm on holidays for the week. I just had time to test Dave's commit. I'm really impressed by the quality of the Graphical Query Builder. It's a really great addition to pgAdmin. Here are some more stuff to add: 5. Adding columns myself which could be the result of a function (count(*) is the first one to pop on my mind, but user functions would be great to... all I ask for is a simple textbox to enter what we want). 6. Adding a user function in the ordering tab. Thanks again. Regards. -- Guillaume. http://www.postgresql.fr http://www.dalibo.com
Hi Luis,
Luis Ochoa wrote:
* GROUPBY & HAVING could be implemented the same way, we did for ORDERBY & CRITERIA respectively.
* One way is - we create a toolbar near the join for changing the join-type.
* And other is - we enable the UP/DOWN keys to change the join-type, while join is selected. But, the problem with this is - this feature will not be directly visible to users, and they won't be able to use until they experienced it. :(
So, I am thinking to go for the option one only.
I will send a patch for it when time permits.
I have something else in my plate on priority basis for right now. :(
Thanks & Regards,
Ashesh
Luis Ochoa wrote:
I think - you're right. :)(...)
By the way Ashesh as I notice you know the tool I'm going to make you some commentaries:
I have been thinking a way of adding the group by and having operators to the GQB to basically allow the user to create more complex queries, but I'm not sure about the correct user interface to do this task, I think that group by can be as the ordering tab and the having tab can be as the criteria tab. Do you have any suggestions?
* GROUPBY & HAVING could be implemented the same way, we did for ORDERBY & CRITERIA respectively.
I was also thinking about this option.
And about the join panel as I told you I was thinking that if the user select one join should be an easy option to change the query type like a floating toolbar with button with the join types that will be show near the selected join. What do you think about this?
* One way is - we create a toolbar near the join for changing the join-type.
* And other is - we enable the UP/DOWN keys to change the join-type, while join is selected. But, the problem with this is - this feature will not be directly visible to users, and they won't be able to use until they experienced it. :(
So, I am thinking to go for the option one only.
I will send a patch for it when time permits.
I have something else in my plate on priority basis for right now. :(
Thanks & Regards,
Ashesh
Hi Luis & Guillaume,
Guillaume Lelarge wrote:
But, I think - it requires a lot of design change.
Thanks & Regards,
Ashesh
Guillaume Lelarge wrote:
Luis Ochoa a écrit :While working on joins, I thought the same that we're missing subqueries and functions in Graphical Query Builder. :(On Wed, Dec 3, 2008 at 6:13 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com <mailto:ashesh.vashi@enterprisedb.com>> wrote:
(...)
Now I publish a list of what I think will be useful functionalities on the GQB if someone desiree to contribute:
1. Add Subqueries, this probably requeries multiples tabs for query.
But, I think - it requires a lot of design change.
This could be a very interesting one. :)2. Add Support to composite types.
3. Add a new skin for the graphics probably with a scroll on right and showing always all the columns (fixed at top) but the other columns can be move up/down with the scrollbar (an option can allow to choose between this and old graphics). And each table have a minimize (shrink only to table title),restore and remove from query button just as a window in a graphical operative system.
4. Add Save/Load functionality (probably xml).
Also thought about missing functions in column & ordering tabs.
Ashesh and Luis,
Sorry for not being available to test and comment, I'm on holidays for the week. I just had time to test Dave's commit. I'm really impressed by the quality of the Graphical Query Builder. It's a really great addition to pgAdmin.
Here are some more stuff to add:
5. Adding columns myself which could be the result of a function (count(*) is the first one to pop on my mind, but user functions would be great to... all I ask for is a simple textbox to enter what we want).
6. Adding a user function in the ordering tab.
Thanks & Regards,
Ashesh