mini-stef / core-data-model-editor

The place to get help, report problems or request feature on the Core Data Model Editor app.

CoreData Model Editor

CoreData Model Editor is a macOS app that allows you to graphically edit a CoreData Model file (.xcdatamodeld files). The good old CoreData graphical editor that was present in XCode disappeared when XCode 14 was released, only leaving the table based editor. This is a nice editor, but nothing is better than a diagram... I wrote this app to help me with my CoreData models, and decided it could help others too.

V1.1 is now available and... it is an editor !!!

V1.0 was able to graphically visualise the model. Now, the model can be edited too !

Included features

• Graphical representation of entities, their attributes and their relationships.
• Edit the model as you wish, any entity, any attribute, relationships, create new model versions etc...
• Search the model for a string; all entity, attribute, and relationship names that include this string are found.
• Quickly see which entities are part of a configuration thanks to colours.

Features to come

• Better validate input texts. Today, inputs texts are used as-is. It would be better if they were checked. For example, an entity name shall not start with a digit character.
• Managing Fetch Requests.
• Show the diff between two model versions.
• Show the type of attributes, and the delete rule at each end of a relationship.
• Show model errors & warnings (e.g; missing type for an attribute).
• Manage individual .xcdatamodel files (today only .xcdatamodeld files are managed).
• Show model warnings or errors.

Where to get the app

The app must be downloaded from the app store: https://apps.apple.com/us/app/coredata-model-editor/id6449733666

But wait ! It's not a free app !!!

Yes, that's true. The reason is that I would like to cover the developer annual fee to keep it on the App Store. Also, that keeps me motivated 😀. But it is very cheap, and it is a pay-once-get-it-forever app. The price may go up as more features will come to the app, so don't hesitate to buy it right now, you'll get all the future features for free 😇.

Where to get help, report a bug, or request a feature ?

You're at the right place. Just issue your report or feature in the relevant section.

core-data-model-editor's Issues

Don't allow relationships to be their own inverse

Problem

A relationship between entity X.rel1 should not be allowed to select as inverse entity X.rel1

Suggestion

Don't put entity X.rel1 in the pick list when selecting the inverse for entity X.rel1

And what happens if you do choose that option?

• User can create this, giving this graphical representation.

• The data can be saved to disk.

• And the saved data can be loaded from disk by the app.

• And the data is then shown as above.

A way to export the diagram

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Trying to see the whole diagram is hard and the only way to see it is to print it, but it doesn't print for some reason

Describe the solution you'd like
A clear and concise description of what you want to happen.
An option to export a JPG, PNG, or even an svg of the diagram

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
There's no other way, not even another app or service

Additional context
Add any other context or screenshots about the feature request here.

Constraints in the model file are not preserved

If you load an xcdatamodel file (set), the XML fields about uniqueness constraints are not visible in the app.
Worse, they are not stored if you Save an updated version of the file.

Steps to reproduce the behavior:

1. Create a simple model using Xcode
2. Add a constraint (e.g. Name or UUID is unique)
3. Save model in Xcode (happens automatically, Ctrl-S to be sure)
4. Load model in app
5. Save model in app
6. Load version saved by app in Xcode

Expected: constraint is still there in xcode.
Result: constraint is gone.

.xccurrentversion file is not preserved

The file .xccurrentversion file is lost when the .xcdatamodeld file is edited by the app.
It contains which version is the current model version, as used by the current version of the app code.

Drag a selection of entities to other part of the diagram

Is your feature request related to a problem? Please describe.
When I try to reorder a diagram with many entities it could be easier to do some local ordering of nearby related entities and then drag the whole group towards other part of the diagram for further reordering. Currently I didn't find a way to do that and need to drag the entities one by one to the other part of the diagram.

Describe the solution you'd like
Be able to select a group of entities like drawing a rectangle with the mouse or picking them one by on via e.g. cmd + click and then drag with the mouse to move the whole group together to other part of the diagram.

Describe alternatives you've considered

Additional context

Saved datamodel file is too different from same file saved by Xcode.

Lots of fields are in different order.
This makes it difficult to see changes when committing in say GitHub.
Or any other form of diff between Xcode-saved and app-saved model files.

Workaround: edit in Xcode and use app only as a viewer. But then you probably don’t have control over layout coordinates.

Workaround: edit in App only. But then the app needs to read and write all features provided by Xcode (see issue #3).

Menu item "Save..." should be "Save"

"Save..." by convention the 3 dots indicates a menu or more options follow, including the option of canceling.
So this menu item probably should be labelled "Save" as long as there is no dialog box of some sort.

Minor detail. Thanks for the work you put into this app. Really appreciate it. Worth me making a review?

Improve layout of relationships if entities are above each other

Problem

If two entities are exactly or roughly above each other, a connecting relationship runs through the lowest entity's box.
This would also apply for relationships between an entity and itself (e.g. parent to child relations in a hierarchy of Nodes).

Suggestion and Example

If EntityL is on the left and EntityR is clearly on the right, the rendering of the relationship connects EntityL.rightSide to EntityR.leftSide. This if fine.

But if EntityB is on the bottom and EntityT is on the top (but not clearly on the left or right), relationships should not connect EntityB.rightSide to EntitiyT.leftSide (or vice versa). Instead, it would be nicer to connect EntityB.rightSide and EntitiyT.rightSide (or EntityB.leftSide to EntityT.leftSide).

How to detect this? If the two boxes' x-ranges overlap.

How to choose which side? Choose the side with least amount of existing connections at that time (summed over both entities). In the example below, the connection between the two blue entities would then be on the right side rather than the left side. Global optimisation of avoiding crossing relationships might be possible, but require more work.

Setting and saving colors for the entities

The app allows entities to be assigned to Configurations, and configurations to be assigned colors:

• the user cannot directly control the color of an entity. It is set by assigning colours to a "configuration". Regardless of what Apple meant configurations for, this should work fine, especially if you have multiple entities per color. But...
• the user cannot directly control the color of a given configuration: if you want blue, you have to generate new configurations until you find one that is associated with blue. The app looks like it was prepared to allow you to choose a color using a color picker. This would help because there are only a few colors supported. And some are unsuitable for combining with white or with black font (depending on MacOS light or dark mode).
• I need to check if the colors are conveniently persisted, and whether the colors survive an editing round trip through Xcode. I saw that they are stored in an extra data file, so the app's intention is clearly to persist the colours, but I thought there was an issue there (sorry for fuzzy bullet: I will check and update this next time that I use your app).

Thanks for the v1.2.0 update! I am particularly happy that at some point you plan to support Swift Data as well.

It is hard to move entities

Is your feature request related to a problem? Please describe.
Need to move entities so that the relationships have minimum intersection and are easy to follow.
Currently this is hard as I need to click on the arrow end, and this isn't easy and takes time.
There are cases where there isn't an arrow end coloured in green, which makes even harder to hit it right, so it can be dragged.

Describe the solution you'd like
I'd like to be able to drag an entity when I click on it, instead of a relationship arrow ending in it.

Describe alternatives you've considered
It could be cmd + click, or whatever, it will resolve the problem.

Additional context
If the initial graph is processed in a way to minimise relationship arrows + entity boxes intersection it would limit greatly the needed entity reordering.