Add database diagrams #1962
Add database diagrams #1962
Conversation
This model represents the list of available db tables. They can be dragged onto diagram. Tables, that are already displayed on diagram, are greyed out and can't be dragged.
Tables represent database tables, and Relations represent foreign key constraints.
This is just a naive scene interface implementation. Items can't be resized or moved, or dropped onto it. It's coming soon©
We use subclassed proxy widget, that overrides overridden mouse event methods and just returns default scene mouse events.
…to 0xd800-diagrams
Use contextual menu of DB Schema dock to add tables to diagram. This might make redundant the current table list internal to the scene.
|
I've taken a look to this. I made a quick change to add the tables to the diagram.
This is the list of implemented work so far:
Pending minimal work:
Items to be discussed:
Features that would be nice to have, but not essential:
|
|
@schdub Ping. Just in case this is still an area of interest for you. 😄 |
Reduce diagram tables width using the size hint of the table name label.
|
Awesome! This looks already much better than I dared to imagine 👍
I fully agree with your approach here. I guess the embedded list was just there because the code is quite old and we probably didn't have the schema dock back then.
Makes sense. I just forgot to add it to
Probably yes. As for the "Database Structure": It does make sense but I'm not sure how habit-breaking it would be for long time users. That said, we have all these issues regarding multiple instances of the Browse Data tab and I have just started working on this. It's probably going to take a long time until we have this actually working but when we add this one day it's probably a good time to rename the old tabs as we like. |
|
Should the tab be named "Database Diagram"?
Graphical schema? Titular Thankful Tabular Table View? Diagramatical
Schematicy Thingy?
|
|
From memory, the "official" name used for these kind of things is Entity Relationship Diagram (ERD). eg a diagram of the Entity Relationship Model That being said, it's probably not the right term to choose as almost no-one would know what it means. 😉 |
|
So I was close then..... ;)
|
Sure :-) If you wish to get some inspiration you can also take a look at how DBeaver (open source Java software) has implemented this same feature: |
When a new table is added to the diagram, its relations to parent and child tables are added too. The lines connecting the tables have start and end positions based on the table proxies representing the table in the diagram. When the tables are moved, their relation lines are moved too.
|
The purpose of "Show tables lists"? A user would expect to click/right click/drag a table from that list onto the diagram pane. Doesn't work. Knowing to select a table from "DB Schema" seems counter intuitive and makes the "Show tables list" redundant/waste of space. The "table magnet" action going on is painful. Selecting a table and moving it around causes another table on the display to be "repelled" to a new location. I can see users getting ticked at this "feature". One thing that would be "nice", harkening back to my MSAccess days, would be to generate "automagically" the diagram from the structure of an existing database. This then begs the question...have we accounted for the one-to-one, one-to-many, many-to-one, and many-to-many type relationships that can exist between tables? This needs work... |
Yes, it would be redundant. "Show tables lists" was the idea of the original author, but now with the Schema dock, it makes more sense to add the tables from there. For making the action more intuitive, I'd add a message to diagram scene when it's empty: "Add tables to this diagram by dragging and dropping them or using the contextual menu from the "DB Schema" dock" When the first table is added, the message will be deleted.
There isn't any magnet if I understand what you mean by that correctly. The question is: the scene has an initial dimension equal to the panel, when you move a table outside of that frame, the scene grows and the center of the canvas moves. This might give the impression that the other tables are moving, but in fact it's the scene view what is moving.
Would be easy if we know how to layout the tables correctly. An initial vesion could simply add them in a grid layout independently of the relations they have: so the relation lines could form a mesh, but would be a start.
That is used by MS Access for automatically generating queries, isn't it? Since we are not currently generating any query on behalf of the user, relations different to the established by the foreign key constraint are probably out of the question, at least as a first step.
Undoubtedly! |
|
Can be useful: |
|
@MKleusberg @mgrojo @scottfurry Any idea how much tweaking this would need, to get it working for putting in our nightly builds? Am thinking that since we've branched off the |
|
@justinclift - yeah. I'm guilty here. It fell off my "projects" plate. I'm in the middle of python stuff at the moment and didn't get to this. |
|
No worries, I have that happen all the time too. 😄 |
MKleusberg
force-pushed
the
master
branch
5 times, most recently
from
d396227
to
16035be
Compare
|
@MKleusberg I've seen various open issues requesting this feature (#913, #1260,and #2034). Any chance someone will work again on this eventually? |
lucydodo
force-pushed
the
master
branch
3 times, most recently
from
4bc0c36
to
e0a000c
Compare
lucydodo
force-pushed
the
master
branch
3 times, most recently
from
7cf9760
to
6aa288c
Compare
lucydodo
force-pushed
the
master
branch
3 times, most recently
from
a7aaabe
to
c433beb
Compare
See #1961. This is a copy in our local branch. I have adjusted it to get it to compile and added some missing pieces. However, none of the actual drawing code seems to be there, so you don't see anything. Not sure how much work is needed there. Is anybody interested in finishing this?