Azimutt - Explore your database, thanks to Elm ^^

Looks really cool ! Congrats !

However, I have some issues finding “paths”. I tried with the “wordpress” example, and the app fails finding a path between “users” and “posts” (whatever the direction of the search).

Hi @sebbes
Thanks for your feedback, indeed, the “find path” feature is built using foreign keys, but the wordpress schema doesn’t have any (:sweat_smile:), even if they do joins, they are not structurally enforced by the database schema.
One thing I plan to fix that is to allow users to declare some links manually so the find path could use them.
If you want to try this feature, use the schema, or your own (if it has foreign keys) :wink:

Hey @loicknuchel, I mainly wanted to add some praise. The app seems really well thought out, particularly the control you have over what to include in the diagram and the ability to save different views. This feels like the workflow I never knew I wanted until trying it just now.

One niggle I ran into was that there were many errors parsing the schema. None of them were important in terms of exploring the schema but I was left with a lot of notifications to close on the right. A close all button would be really nice.

edit: for convenience I added an issue, If you think it’s a good idea I’d be happy to add it myself (not quite sure how the ux would work so open to suggestions here).

Hu @opsb, thanks a lot for your kind words. It means a lot to me as it shows it didn’t code only for myself a strange app ^^
Do you mind if keep your words for some testimonials ?

Right now I’m improving the parser so hopefully you will not have errors soon :wink:

Thanks a lot for the issue and the PR proposal, it’s very welcome :slight_smile:
Don’t hesitate to reach out if you have any question about the code. And if you have some improvement suggestions, they are also very welcome (this is my first Elm app ^^).

Hey, yep very happy for you to use my words and I’ll take a look at adding the PR tomorrow.

1 Like

Nice! Really beautiful app and it works quite smoothly. :grin:
I especially like that you can start from scratch and build up the graph with only the tables which you are interested in. In some other tools it’s always quite an info dump.

Speaking of other tools: If you haven’t yet, you should check out Salesforce’ Schema Builder, there might be a few features to steal. :stuck_out_tongue:

Is there any chance that you extract your graph rendering code into an extra package? I’m planing to build something similar and a graph rendering library would be a great starting point. :innocent:

1 Like

Hi @ad-si
Thanks for your kind words :slight_smile:

Yep, I started it out of the frustration of other tool that become quite useless when you have 50 > tables (I have 750 right now :scream:). Pretty happy you like this choice :slight_smile:

Thanks for the link, will definitely check. Is there any specific feature you would like to see ?

Regarding the graph rendering as an external package, to be honest I don’t know… It’s not I don’t want to but I’m not really sure how to do it properly while keeping the flexibility I need for Azimutt and I doubt to find some time for this ^^
But we can definitely discuss about this and if you have a code proposal I would be happy to review it

Holy moly, 750 is quite a number. :sweat_smile:

Is there any specific feature you would like to see ?

Nothing in particular. Salesforce is just quite good at high density UIs. E.g. the curvy connectors (which you probably already have on your radar) and checkboxes, instead of the hard to differentiate eye / crossed out eye would be an improvement.

while keeping the flexibility I need for Azimutt

Yeah, that’s a good point.

I might simply start with borrowing some code from you. :innocent: Maybe we’ll figure out some synergies along the way!


Nice project! I could see this being a very useful way to document and explore, and potentially collaborate with others on a schema description.

A few other things I’d like to see:

  1. Manual settings of relations. Not every application has foreign key relations defined, so it would be very useful to be able to define and save these in the app.
  2. Related to 1, in some cases join conditions can have more complex clauses such as “ = + 1000”. Would be good to be able to specify these as well.
  3. Multiple databases/schemas supported in one project. In some cases it makes sense to join related table across databases.

Also may I suggest that you make it clearer which dialects of SQL are supported for schema import?
Seems like Oracle doesn’t work.

Keep up the good work!

Yes, I wanted to do them at the beginning but after noticed they are nicer but not so useful, so I focused more on features. But one day I will work on them :wink:

Yeah, feel free. If you see some possible improvements, don’t hesitate to open an issue or PR :wink:

Hi @bogdan-k

Thanks, very happy you like it :smiley:

Also your suggestions are pretty good, I had some in mind :slight_smile:
It’s still early and I focus more on improving UX and smoothness right now but I plan a lot more features like you suggested:

  • multiple databases
    • Being able to update a schema
    • Being able to load different schema files
    • Being able to select which database are used
  • relations
    • manual relations (as a fallback when I fail to identify them)
    • extract relation from code (ex: Ruby on Rails ArctiveRecord), also polymorphic relations
    • define a standard format so you can parse/write your own data and import them

Your point 2 is interesting, what is your use case? Documenting your database? (manually within the app? from imports?)
Can you develop a little bit ?

For SQL dialects, the goal is to support them all but you are right, currently I’m more focused on PostgreSQL and MySQL… But I will add it asap.

1 Like

Thanks for your answer @loicknuchel !

I’ve tested with the and I had this result to go from talks → users :

I know this is experimental feature, but here are some suggestions:

  • we have 4 talks > users > contacts paths with no way to distinguish between them. Having the fields used to follow the path would be helpful!
  • the “direction” is unclear: to go from talks to users, we have a foreign key from talks to users. For the users > contact this is the contrary (foreign key from contact to users). Maybe it worth indicating this in some way like talks > users < contacts.

Hi @sebbes

Thanks for your message, and indeed, this is for this very reason this feature is still marked as experimental!

Two answers:

  • You have 4 times the path “talks > users > contacts” because they are using different paths (using created_by & updated_by fields in two tables lead to 4 path). For this, I added the “Search settings” just above so you can ignore such fields (created_by and updated_by) so you will have much less possibilities with less “strange” results
  • In fact, you have the used foreign keys as a title for the joined table (if you hover “users” or “contacts” table you will see which fields are used and in which direction. Totally agree, this UX is quite bad but I haven’t found a good one yet, so for now it will stay like this in experimental stage

The few ideas I have for now:

  • have a default list of fields to ignore (created_by, updated_by, deleted_by and their variants)
  • add a dashed underline on joined tables with a tooltip, so you are notified there is something special and the text appear immediately, not after a few seconds

I think this could improve the UX but it’s still quite far from good one… What do you think about theses suggestions ? Do you have others ?

add a dashed underline on joined tables with a tooltip, so you are notified there is something special and the text appear immediately, not after a few seconds

Yeah, having the tooltip appearing immediately on hover would be really helpful. Because I did hover the line but I didn’t stay long enough on the element and the tooltip didn’t showed up (that means you’d need to track this hover state on the elm side and displaying it with a position: relative property or so).

Another way would be having a > chevron on the left of the line which turns into a v when we click on the line and would “expand” the path vertically.

Also easy improvement with this is to use → and ← UTF 8 arrow, whic looks way nicer than -> :slight_smile: .

have a default list of fields to ignore (created_by, updated_by, deleted_by and their variants)

I don’t get it, do you want adding a list of ignored fields for all the schema being loaded? What about the schema is written in French (au fait, salut depuis Paris!)? Or use different convention like creator instead of created_by?

About global layout, I’d move the search modal on the left menu (you could have two tabs: “Tables”/“Search”). This way, we can still see all the tables and parametrize the search accordingly to what we see. (Generally speaking, I tend to avoid modals since they break the “flow” and hide data; e.g. what if there is a long and complicated field I’d want to ignore in the search and I want copy paste it from the table? I’d need to close the modal, copy the field, reopen the modal and paste it).

Last thing: are you aware the “deepth limitation” in the doesn’t work (I know, this is experimental feature, but I prefer to warn you)?

Thanks for your suggestions, I did some improvements:

  • tooltip is now appearing immediately with a dotted underline indicator
  • replaced -> by :+1:
  • added option to expand a result and show the needed joins (hope it will helps)
  • added some messages to remind of settings :wink:

Regarding the search itself, prefilled ignored fields will only be the default value (to catch common cases), but anyone can change it depending on their needs (no way I can guess what is relevant or not ^^).
About the path length, it’s limited to 3 by default but you can change this in the settings (at the beginning of the modal)
I agree modals are not a very good UI, they were the easy way to get my features out and have feedback, now I take more time to improve them :wink:

Would be happy to have your feedback on my (small) improvements :smiley:

PS: for the tooltip I currently use Bootstrap so they are not related to my Elm model, but I’m transitioning to Tailwind with a goal to have them (among other things) in my model. Do you have an idea how to do that? Send a message with an id to know what is hovered ? (I do that for columns but I’m not sure it’s very efficient)

Yes. A common use case is that we have some vendor database(s) that we are trying to make sense of and build a knowledge base for over time. We want to build a model of how tables relate to each other, and to annotate the meaning of certain fields, etc. It would inform new queries and views that we would create.

I see your app as potentially being the tool that we could do that with. Especially if it had collaboration and code-gen features at some point in the future.

Hope that helps illustrate the use case.

I totally get your point, thanks!

I didn’t thought of the “understanding vendor database” use case and it’s a great one :+1:

About collaboration and code-gen, this is planned. But clearly not in the near future as I’m looking to expand the primary use case which is exploring and understanding a schema (except if I had a lot of requests for this, I could adapt the roadmap ^^)

Yeah, that’s way better ! Nitpicking: the tooltip sometime wrap and takes 2 lines, would be great having some white-space: nowrap; in the tool tip.

About the path length, it’s limited to 3 by default but you can change this in the settings (at the beginning of the modal)

Thing is I have really long path, greater than 3, e.g.:

About the tooltip, actually, there might be a way displaying it only using :hover pseudo property (the same for the highlight of your columns). Though, doing so will force you rendering all the tooltips in the DOM which can result in a big node number, which might result in performance bottleneck. Otherwise, what you describe would be the way I’d go.

1 Like

@opsb Hi, I updated the landing page with you words, feel free to ask for any change if you want to.

@bogdan-k I plan to add manual relations this week, I hope you will like them :wink:
For annotating tables, columns and relations, I will be for next week if everything goes weel :timer_clock:

Last week I also added a group selection feature, so now you can select a few tables (ctrl+click or area selection) and move them all together or zoom on them :tada:


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.