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

[vdhamer]

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).

[Mini-Stef]

Hello vdhamer, Yes, the fields are saved in a different order, because I can't know how Apple is ordering their fields, nor make sure they'll keep the order in the future. This said, the underneath format is XML, so order just doesn't matter.

I understand the concern if you want to diff between two versions. But I'll put that on a low priority, because, after some thoughts, I think I can do better than what is today, but I can't guarantee a full clean result.

[vdhamer]

“I think I can do better”, but don’t expect output to be 100% the same.

Almost the same would be quite helpful already. Somebody with a datamodel will initially want to do a diff to see if your tool is safe to use. A few cosmetic differences is no issue. But right now about 80%-90% of the lines are different, and the difference between corresponding lines is so large that the diff algorithm I ran looses track of which lines match between the two files.

There exist XML specific diffs that look at content and ignore order, but it would be nicer if the differences are smaller. Also useful if you want to do unit testing: checking if output is the same as input for a bunch of datamodel files copied from github…

Testing for equality of xml files having different ordering of nested elements Essentially these algorithms compare parse trees instead of lines of text.

Peter

Sent from my iPad

On 12 Jan 2024, at 18:52, Mini-Stef @.***> wrote:



Hello vdhamer, Yes, the fields are saved in a different order, because I can't know how Apple is ordering their fields, nor make sure they'll keep the order in the future. This said, the underneath format is XML, so order just doesn't matter.

I understand the concern if you want to diff between two versions. But I'll put that on a low priority, because, after some thoughts, I think I can do better than what is today, but I can't guarantee a full clean result.

— Reply to this email directly, view it on GitHubhttps://github.com/Mini-Stef/Core-Data-Model-Editor/issues/4#issuecomment-1889721523, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADGGUWAKBDIBGL3OOMTF4ITYOFZ65AVCNFSM6AAAAABBYBI2HKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBZG4ZDCNJSGM. You are receiving this because you authored the thread.Message ID: @.***>

[Mini-Stef]

Hello Peter,

I think I did a pretty good job this week-end in mimicing how Apple is generating their XML files. I now generate files that show no differences if untouched, provided that:

1. The user doesn't change the number of spaces per intendation (which is configurable in XCode...)
2. We don't look at the "unmanaged" parts, such as constraints, user info, fetched properties, composite types, fetch requests. Those parts are now kept, so as the issue#3 you raised should also be solved, but order is not guaranteed.

I should be ready to issue revision 1.2.0 this week, but before that, can I ask you a favor ? Would you mind sending me some model files that you have with which I could perform more "real life tests" ? I would for sure plainly understand that you can't or don't want to, but that would be really great.

Thanks,

Stef

[vdhamer]

Great to hear you made significant progress in only a few days.

Would you mind sending me some model files that you have with which I could perform more "real life tests" ?

No problem. My project that uses Core Data is open source. There are 4 tables/entities right now (6 soon). It uses uniqueness constraints on most tables.

You may want to use a specific labeled version or commit for your testing: the latest version of the model may still change. The builds (TestFlight betas) and releases (App Store) with GitHub release labels are, of course, frozen.

github link

Here is a simpler 1 tabel model (that I created just for practice). It contains a simple constraint. It won’t change anytime soon.

[Mini-Stef]

Many thanks !

I did the test and indeed, no more differences between XCode output and CoreData Model Editor output. I'll release revision 1.2.0 that solves issues #2,3,4 in the few next days.

And thanks for your review, very much appreciated.