.xccurrentversion file is not preserved

[vdhamer]

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.

[Mini-Stef]

Hello,

Ho woaw ! I was desperatly looking for how the version to use was stored, and you just gave me the answer. There is this hidden file .xccurrentversion !!! Thanks for the tip, and yes, I will solve that !!!

Next mystery is how to know the order of the versions (so that the app code can do a light migration). To me it seems this is only based on the name of the model files...

[vdhamer]

order of the versions (so that the app code can do a light migration) probably only based on the name of the model files...

Hmmm: they don't tell you how to name the files. And they append things like 2 to avoid duplicates, but I remove those spaces each time.

Here is a fragment of a diff between an older and newer version of .xcodeproj/project.pbxproj. The diff was made using Github.

It contains another copy of a usable currentVersion. And maybe the list of GUIDs of children is by definition newest-on-top.

Evidence (weak) that this is the right spot:

• they are listed in the right order
• the actual file name is formatted as a comment. The Guid is linked to a file name earlier in the file, I think.
• the info is near currentVersion =

So now, instead of "can't find where it is stored", the question is which of the two data sources to trust. We have a project.pbxproj file which has what might be an ordered list. And a .xccurrentversion. And the same data in the .xcodeproj/project.pbxproj file. Are they always the same (probably). If they do differ, which one is right? Maybe not of practical importance.

A guess: maybe they first weakly integrated their editor(s) into the IDE. Then their editor updates .xcdatamodeld without caring about Xcode files like pbxproj. But now they read that into the pbxproj file because they have all the file dependencies there. So the current version of the entities and relationships are needed for building/making the project. So should be near all the other make dependencies to generate the required Swift/ObjectiveC class definitions.. And indeed the history is needed for (lightweight=easy=automatic) data model migration.

[Mini-Stef]

The thing is, I can't use any information that is not inside the .xcdatamodels folder (such as the .pbxproj), as this is what the App takes as a document. I just don't have the XCode project, only the Data Model. So I think I need to rely on the alphabetical order...

[vdhamer]

I would do some simple experiments to confirm how Xcode determines the sequence of the migration chain.

I still am not convinced that Xcode uses string sorting (because Xcode has no control over the strings chosen by the user). Hoever, it would work for most users (including me and apparently you). In cases where it would fail, you get something which the user probably cannot figure out anymore…

The link below indeed claims that the order is controlled via the sequence of .xcdatamodel children in the .pbxproj file. Yes, I know you don’t want to load that file in the app. A hack would be to use string sorting when the names look sensible, and fall back on a modal file picker asking the user to select the appropriate .pbxproj file if the app cannot find it automatically. I understand that this would fail if somebody receives a standalone .xcdatamodeld file without a complete buildable environment. But do people actually do that (e.g. a specialist that only does core data, but cannot build the project)?

https://stackoverflow.com/questions/8314957/change-order-of-xcdatamodel-entries-in-xcdatamodeld-file @.*** Change order of .xcdatamodel entries in .xcdatamodeld filehttps://stackoverflow.com/questions/8314957/change-order-of-xcdatamodel-entries-in-xcdatamodeld-file stackoverflow.comhttps://stackoverflow.com/questions/8314957/change-order-of-xcdatamodel-entries-in-xcdatamodeld-file https://stackoverflow.com/questions/8314957/change-order-of-xcdatamodel-entries-in-xcdatamodeld-file

Sent from my iPad

On 26 Jan 2024, at 08:24, Mini-Stef @.***> wrote:



The thing is, I can't use any information that is not inside the .xcdatamodels folder (such as the .pbxproj), as this is what the App takes as a document. I just don't have the XCode project, only the Data Model. So I think I need to rely on the alphabetical order...

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

[Mini-Stef]

Hello, So, I investigated a bit, and here is my main conclusion : I don't need to look at the file order :-). Here is how I came to the conclusion.

First, what is XCode doing ? Well, XCode compiles the model version files into the app bundle. For each .xcdatamodel file, a .mom file can be found in the app bundle, plus a .omo file. This .omo file gets the name of the current model version - and I guess it also includes some information on the order of the successive version, or some information that helps lightweight migration in some way.

That information indeed comes from the order of the file that can be found in the .pbxproj file, which is in fact the full ordered list of the XCode navigator (folders, files etc...). But you can't modify the order of the .xcdatamodel files inside the .xcdatamodeld file by drag&drop in the same way you can for normal files. Because this order is the one that will be used for migration and somehow reflected in the .omo file. When you create a new version, XCode ask you the name, but puts this version on top of the others, and because the order can't be changed later on, that's how the order is created.

And that's a problem, because, in CoreDataModel Editor, one can remove or add .xcdatamodel files, and they are not known by XCode, they don't appear in the navigator, and you can't add them manually. The only solution is to edit the .pbxproj file, which is difficult because files appear at several places, with various attributes and checksums.

So, the bad news is that using the version add/remove buttons in CoreDataModel Editor is to be discouraged, because those modifications can't be reflected in XCode (unless you edit the .pbxproj file). I'll add a clear warning for that. And I won't edit the .pbxproj file because it's really too complex.

The good news is that:

• I will add the . xccurrentversion management, it's easy, it's part of the . xcdatamodeld file, and I can even have CoreDataModel Editor to change the current version
• I don't have to look at the order of the files, because that's important only when compiling, and that's XCode job.
• For diff, I will ask to which version to diff
• And I will discourage adding/removing versions with some clear warning to avoid getting out of synch with XCode.

[vdhamer]

I am curious why you would discourage using this app feature, rather than removing it. Are there cases where it is useful and safe to use?

On 26 Jan 2024, at 21:37, Mini-Stef @.***> wrote: And I will discourage adding/removing versions with some clear warning to avoid getting out of synch with XCode.

[Mini-Stef]

Hello,

.xccurrentversion file is now saved throughout modifications. That will come in version 1.3.0.

I keep the topic open until I find a nice way to solve the other problems discussed in the thread.