[eFEAT] Change database folder on Mac OS X

[pierpaolocira]

Under Mac OS X the dabase folder is placed under the home directory of the user. [edit: both the folder "db" and the file "user.xml"]

I would not recommend to find a way to place it "under" the application folder (because it might be overwritten in case of updates).

MacOSX application data should be placed under "userhome/Library/Application Support/".

If this is not possible, then I would recommend to add anothere level in the direcoty organisation: "hattrick" and to place it in the user folder. In this way final destinations will be "\~/hattrick/db/*" and "~/hattrick/user.xml".

Otherwise there might be conflict with other applications using the folder "db" [or the user.xml file] and this could also be counterintuitive for users that might e.g. delete it by mistake.

In both case we should also include an automatic "migration procedure" that would simply:

• detect if the new location exists
• if not (and the old location exists) to perform the migration. This procedure could be kept for 2-3 versions and then being removed.

[tychobrailleur]

Totally agree with that one, and may even get a crack at it — this has been nagging me for some time. ;-)

[akasolace]

@pierpaolocira @tychobrailleur I fully agree with this

I have been trying (in a vm) to set a diferent location for HO folder, but I did not find a way. This is also why it is not possible to upgrade HO under macOS while it is possible under windows and Linux.

So if you manage it, I guess it means you will also make possible upgrading HO from macOS, that would be a big one

[tychobrailleur]

So if you manage it, I guess it means you will also make possible upgrading HO from macOS, that would be a big one

Not sure I get what you mean there?

[akasolace]

In windows and Linux version of HT, it is possible to do help -> check new version and upgrade directly via the app. If new version exist, it dowload files and upgrade directly, no need to do this manually as it is the case on macOS

[tychobrailleur]

Sorry for being thick @akasolace and this may be due to my lack of knowledge about the upgrade process, but I still don't see what is preventing us from doing automated upgrades on macOS today: as @pierpaolocira indicated, user.xml and the db folder are created in the user's home directory, whilst all the HO files are (supposedly) installed under /Applications/HO — an automated upgrade would theoretically replace the files under /Applications/HO and leave ~/user.xml and ~/db/* untouched (same as on Linux I would have thought).

[pierpaolocira]

Apart from the discussion here, I have forgotten the user.xml file. I'm going to update the initial description of the issue, because the solution to simply rename "db" to "hattrickDB" will continue to keep that file in the user directory.

[akasolace]

@tychobrailleur @pierpaolocira maybe it is possible to make the upgrade work on macOS but personally I did not manage to do it. A bit of background information.

At the time I had an old macOS VM to make some test, I could see the app was running ok but the upgrade was throwing error. If I recall correctly (this was 18 months ago) it was because it was not possible to copy new jar and folder within the app folder. At the time I also tried to make the db folder and user xml within the app folder but I also did not manage. On SO a user told me my issue might be because I was using an old version of macOS (java was apparently packed differently at the time on mac platform). Hence I tried to upgrade macOS within my VM but I broke it ( I spent few hours trying to repair it then I gave up). I contacted previous HO dev and he told me that update under macOS has never been supported so he could not help either. Considering you are under macOS maybe you will find a solution ... which would be great news !

[pierpaolocira]

I think the biggest issue is the MacOS has strict rules on ".app"... this is why the "famous trick" is needed in order to authorise HO to run. Allowing to directly change the content of an application is a very bad practice for security reason IMHO unless it's managed by proper permissions at OS level... That's the reason, I imagine, why the majority of the MacOSX applications cannot update automatically (see LibreOffice or Filezilla, justo to mention a few)... and I really wonder what has to be done to allow autoupdate as, e.g., Firefox does. In any case this topic will come back again because I read somewhere that future versions of MacOS won't allow anymore the "magic trick" to launch an applicationif not signed by a developer...

Maybe this discussion can be done in a separate thread... for the time being I would emphasize that my proposal is either to create a container folder "hattrick" into the home directory of the user, or to use the "Application support" folder (that is not the "Application" folder).

Maybe we can also consider the possibility to manage different DBs (e.g. "Hattrick", "Hattrick-DEV", etc.) so that developers can have different Hattrick installations linked to different DBs, withouth risking to damage the real DB that they use to play.

But... @tychobrailleur, I din't understand if you are going to work on it, or if @akasolace can assign it to my spare time.... :)

[tychobrailleur]

But... @tychobrailleur, I din't understand if you are going to work on it, or if @akasolace can assign it to my spare time.... :)

I was contemplating looking into it, but if you have some spare time, feel free to pick it up! IMHO, the right location would be ~/Library/Application Support/HO so my preference would be to have the files there, but making it also configurable would also be great.

[pierpaolocira]

Ok... I'll work on it in order to mobe both the db folder and the user.xml file. @akasolace can you please tell me where those elements are stored under Win and Linux? I need to work on how the path is determined and I would like to do it in a proper way (i.e. not just several if conditions that will slowly made the code unreadable)... this information will help me to check that the code should be OK before pulling it for revision.

[akasolace]

@pierpaolocira in both windows and Linux those elements are initialized within HO folder, i.e. at same level as HO.jar. I do not think this is reproducible under macOS

[pierpaolocira]

...in both windowas and mac those elements are initialized within HO folder @akasolace do you mean Win and Linux?

I don't want to do the same withing the HO app (because DB might get lost in case of update of the application by overwriting the whole .app). I just need (to try) to make sure that I am modifying properly the application.

[akasolace]

@akasolace do you mean Win and Linux?

yes I edited

I don't want to do the same withing the HO app (because DB might get lost in case of update of the application by overwriting the whole .app).

In windows and mac this can't happen because the app does not come with those elements in first place. I do not know mac platform, hence I will let you decide whats best

[pierpaolocira]

In windows and mac this can't happen because the app does not come with those elements in first place. I do not know mac platform, hence I will let you decide whats best

@akasolace do you mean Win and Linux? :) :) :)

Seriously, I would need someone to test this low-level change on Win and Linux when it's ready, before the merge... I will do some first experiments tomorrow... ;)

[akasolace]

@pierpaolocira sorry for the confusion but you got it right :-)

[akasolace]

looks linked/similar to #5 I guess your PR would close both ...

[pierpaolocira]

I started working on it, but I'm a bit out of time... As soon as I can, I will test and go for a PR

[pierpaolocira]

Additionally I found that also "Lineup" folder is placed in the user home. I fear HO is polluting it :) , because it is considered as the application folder... I would like to keep those two fixes as separate (because saving the DB seems to have some specificities), but for Lineup (and any other module) I think that a specific solution (similar to the FileLoader, which is for static resource) should be found. @akasolace should I open another issue for it?

[akasolace]

@pierpaolocira yes it would make sense to put on those file/folder on same place similarly to what is being done for windows/Linux

should I open another issue for it?

no need, it is part of that issue

[pierpaolocira]

should I open another issue for it?

no need, it is part of that issue

OK, but this needs for two separate changes (because the class of the DB is not only about filesystem, but contains also some string manipulation on the URI to connect to the DB etc.), so I will most probably go for 2 separate PR to close this issue.

[akasolace]

OK, but this needs for two separate changes (because the class of the DB is not only about filesystem, but contains also some string manipulation on the URI to connect to the DB etc.), so I will most probably go for 2 separate PR to close this issue.

if you reckon it makes more sense to have it with 2 issue please do , otherwise you can add some sub task to this issue.

[akasolace]

@pierpaolocira where do we stand on this one?

[pierpaolocira]

Too much extra work per day due to current pandemy... :(

Just as a reference for the future:

• last commit was "Implementation to be Tested"
• in order to test I had to fix the gradle file issue, and several weeks have been needed there
• now to test this, I need to look again all the changes in order to remember all the caes to be tested... but I have no time :(

[akasolace]

@pierpaolocira understood, just let me know when progress are made ... and in the meantime stay safe !

[akasolace]

@pierpaolocira I will move this one to milestone 4.0 as I don't think it will be ready on time for next release ...

[pierpaolocira]

Yes, thanks a lot...

[akasolace]

@pierpaolocira I will take it over ...

[pierpaolocira]

@pierpaolocira I will take it over ...

@akasolace very sorry but I am working too hard since the CoVid situation has started... and when I finish to work I have no mental energy to properly deal with this. As mentioned I wanted to make sure that it works properly on Mac and didn't introduce any regression with Win/Linux/Zip distributions (and when working from the IDE)... If you like I can push the related code on my fork... if we are lucky it needs only to be tested, otherwise some (I hope small) changes... I can also describe some test scenario... Please tell me if I should do...

[akasolace]

@pierpaolocira no worry, that's ok I think I have a solution already https://github.com/akasolace/HO/releases/tag/dev