@kiryasolod
I'm working on this point.

There are 2 possible solutions:

1. Store table position in the file as comments.
   Good: Refactoring (changing filename, move file into another location) will take no effects.
   Bad: A bit tricky when store/restore table position while working on the diagram
2. Store in a separated file
   Good: Easy to switch between LocalStorage or File
   Bad: Refactoring could cause broken linked between table position and dbml files

Do you have any ideas?

I think the 2 way is still more preferred. I can see several options to save the association between position config file and the dbml

1. In case of refactoring when the dbml file location is changed, we could restore it manually using vscode command line (Ctrl+Shift+P)
2. We store the dbml file path in the position config file, and if the dbml is not found, when the user opens the dbml trying to render it, you can explicitly ask if this dbml should be associated with one of the position configs located in .vscode (if they're several). Make the user pick one of the configs to restore the association
3. We could come up with the name pattern for dbml file to look at only the name, no matter where it's located. For example, <your_file_name>.000.dbml where 000 is a number of the file in case if there are several dbml files in a project. When the location of dbml is changed, your plugin can run the search attempt to locate the first *.000.dbml entry. This approach is more convenient in case when we have a dbml for each migration
4. Determine the hardcoded location where all dbml files must be stored in a project - but personally I don’t like this option. Plugins mustn't affect the project architecture. In fact, the previous option also affects the architecture but not so much

if you'll allow me to contribute:

saving in .vscode is the most correct option, since the one that will handle the positioning is a VSCODE extension. So if someone else uses another IDE, nothing will be affected

On the other hand, many companies/repositories do not version the .vscode because it is something personal, which will force the versioning of personal preferences to the repository

Since DBML is not something extensible, it might be a good idea to use stick notes https://dbml.dbdiagram.io/docs/#sticky-notes.

This will not interfere with other IDEs. It will not force the versioning of personal preferences, and it might open the way for other extensions and plugins to parse it

One thing to think, is that any minimal change on position will change the file. What can cause alot conflicts. So may with separated file can be the way, because you can just discard changes and get new one from repository.

About the name, i think its need to be fixed, like FILENAME.DBML.positions on the same folder

Hi @scorninpc

It's perfectly fine if you would like to work on this issue.

My initiate version is using comment feature from DBML to store position information directly in the file which I can also use it in the gitlab pipeline to publish another version to gitlab pages so that Business Users can view it without installing VSCode.
This way contains some drawbacks and cause a lot of synchronization issues.
Another idea - In DBML specs, they allow to add some custom properties which supported by pydbml but not in @dbml/core yet. Therefore, I think it could be a good way to use Note in Table to store position information - until @dbml/core support custom properties in Table.
I'm still worry about using a separated file because keep connections of position file and DBML definition file will never be easy and hard to be supported in the future development.

In DBML specs, they allow to add some custom properties which supported by pydbml but not in @dbml/core yet. Therefore, I think it could be a good way to use Note in Table to store position information - until @dbml/core support custom properties in Table.

Good to know this. I think this is the best world:
1 - just like the header color, everything is in one place
2 - no need to invent anything new, it would be in the definition of the language

My only problem is versioning. If a small move is made, the file will change. If someone else also makes a small move, it will change the same place in the file, which will cause conflicts. But I think this kind of problem should be resolved between the repository participants.

Do you already have any code about this?

In DBML specs, they allow to add some custom properties which supported by pydbml but not in @dbml/core yet. Therefore, I think it could be a good way to use Note in Table to store position information - until @dbml/core support custom properties in Table.

Good to know this. I think this is the best world: 1 - just like the header color, everything is in one place 2 - no need to invent anything new, it would be in the definition of the language

My only problem is versioning. If a small move is made, the file will change. If someone else also makes a small move, it will change the same place in the file, which will cause conflicts. But I think this kind of problem should be resolved between the repository participants.

Do you already have any code about this?

There is one more problem in case if we add positioning information to dbml itself. For example, I don't make any modifications in dbml. I write migrations, then execute them in the DB, then I make SQL dump of the database structure, and then I convert SQL to dbml using sql2dbml utility. Of course in that case the dbml will be regenerated and all information about positioning will be gone. So that's why storing the coordinares in sepearate file would be preferred. Actually, I'm not sure that many people use dbml as the origin. I think, many people generate it just to get a graphical representation of the existing DB

@kiryasolod

About the usage of DBML, I'm in the opposite side. In our project, we define schema in DBML and use it as single source of truth. In the pipeline, we migrate all tables if there schema changed. And I think Holistic - DBML maintainers also would like to use DBML as a single source of truth then build everything else around it.

In addition, not only just positioning but other features like TableGroup, Note, Comments don't also work if you just export from SQL to DBML.

But your concern is valid too.

There're no perfect solutions if we just handle it within this extension. That's why even though I implemented it in our internal project (a customized version of this extension) but I don't apply it here.

I am also using DBML with databasediagram.com. It stores position information in the DBML file as a comment and adds a "//POSITION..." line to the end of the DBML file. I am also generating DBML files with code, but it is easy to take the last line of the file edited with databasediagram.com and add it to a new file.

From a versio control point of view, it is essential for me to link position information with the model.