Skip to content

Conversation

Withalion
Copy link
Contributor

@Withalion Withalion commented May 6, 2025

Fixes #1969

This PR adds foundational work for supporting project IDs in mobile app. Besides issue mentioned above this is preliminary work for #1008, #1102, #576, project renaming etc.

Outline of the changes done:

  • core
    • CoreUtils
      • refactor
      • getFullProjectName(), extractProjectName() has been moved from MerginApi
    • Project
      • LocalProject supports UUID type of IDs + new generateProjectId()
      • MerginProject supports UUID type of IDs + new fullname()
      • LocalProjectsList changed to HashMap LocalProjectsDict with ID as key
    • LocalProjectsManager
      • keeps projects in HashMap
      • delete projectFromMerginName(), it was used only by tests
      • new updateProjectId() necessary function for creating new projects on server ( server returns new ID for already existing projects, app needs to adapt to it)
      • general refactor and move from project fullnames to project IDs as parameters in functions
    • MerginApi
      • general refactor, a lot of the functions are never called from QML for example
      • listProjectsByName() stays until there is v2 endpoint for IDs
      • delete migrateProjectToMergin() just a wrapper for createProject() ( i think it was used just by tests)
      • delete projectDiffableFiles() not used anywhere
      • move getFullProjectName() & extractProjectName() to utils
      • change deleteProject() to use immediate deletion instead of scheduled, we use it only internally for project management
      • remove topic parameter from networkErrorOccured() it was only used by tests (they use http error codes now)
      • new projectIdChanged() signal to trigger update of local project ID to server generated ID
      • new getProjectDetails() it's leaner version of getProjectInfo(), the response won't contain versioning history
      • Transactions now keep projectId as key
      • generally everything what could be, was moved to use project IDs, the synchronization workflow couldn't, so for communication with API we use project names but internally the project ID is propagated and used where possible
      • when a local project is "migrated" to mergin there is new request for new project ID generated on server that is further processed and local ID is changed to match server ID
  • app
    • QML
      • just refactor to support project IDs
    • C++
      • ActiveProject
        • new projectId() to get project ID of active project
      • Main
        • rework to project IDs
      • ProjectsModel
        • replaced listProjectsByName() by fetchProjectsById()
        • reworked slots to use project IDs
        • removed porjectNames(), it was used internally and is not necessary since we moved to IDs
      • ProjectWizard
        • refactor, most importantly moved from deprecated QVariant::type to QMetaType
      • SynchronizationManager
        • keeps synchronization processes by project ID
        • reworked to use project IDs instead of project names
    • Tests
      • mostly refactor & minor changes
      • replaced findProjectByName() with template function
      • moved descriptive inline test function comments to header file or written new ones

@Withalion Withalion force-pushed the move-to-project-ids branch 2 times, most recently from 8bf8a20 to 2d54ae3 Compare May 15, 2025 09:36
Copy link

Pull Request Test Coverage Report for Build 15041670829

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 634 unchanged lines in 14 files lost coverage.
  • Overall coverage increased (+0.3%) to 60.661%

Files with Coverage Reduction New Missed Lines %
input/app/projectwizard.h 1 50.0%
input/core/merginapi.h 1 97.56%
input/core/merginprojectstatusmodel.h 1 0.0%
input/core/project.cpp 1 97.22%
input/app/projectsmodel.h 3 25.0%
input/core/project.h 16 46.15%
input/app/variablesmanager.cpp 19 60.28%
input/core/localprojectsmanager.cpp 21 78.74%
input/core/coreutils.cpp 31 82.61%
input/app/projectsmodel.cpp 41 69.52%
Totals Coverage Status
Change from base Build 15018608869: 0.3%
Covered Lines: 8202
Relevant Lines: 13521

💛 - Coveralls

@Withalion Withalion force-pushed the move-to-project-ids branch from 2d54ae3 to 61b99d1 Compare May 15, 2025 10:46
@Withalion Withalion marked this pull request as ready for review May 15, 2025 10:47
@Withalion Withalion requested a review from tomasMizera May 15, 2025 10:47
Copy link
Collaborator

@tomasMizera tomasMizera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed to go through the app folder so far, will continue later!

// In theory we could send that request only for this one project.
listProjectsByName();
// To ensure project will be in sync with server, send fetchProjectsByProjectId request.
fetchProjectsByProjectId( { projectId } );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you fetch state only of this one project, won't other local projects states get unknown (not calculated)? When requesting this API (in fetchProjectsByProjectId) we clear the projects model and so the resulting state of the other projects is now likely unknown (I did not test this, just assumption from the code).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds plausible from the look of it. Will test it later again when the review is finished.


//! Syncs specified project - upload or update
Q_INVOKABLE void syncProject( const QString &projectId );

//! Stops running project upload or update
Q_INVOKABLE void stopProjectSync( const QString &projectId );
Q_INVOKABLE void stopProjectSync( const QString &projectId ) const;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one should not be const, it alters things (maybe not directly, but it does)!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with that it changes some things. We should probably have some discussion about using const and in what cases is it intended to use.


//! Forwards call to LocalProjectsManager to remove local project
Q_INVOKABLE void removeLocalProject( const QString &projectId );
Q_INVOKABLE void removeLocalProject( const QString &projectId ) const;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I believe this one should not be const.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing as mentioned above.

@tomasMizera tomasMizera added the FROZEN 🥶 do not merge before upcoming release label Jun 5, 2025
@tomasMizera
Copy link
Collaborator

tomasMizera commented Jun 26, 2025

From our discussion earlier today:

For sync:
image

For listing downloaded projects:
image

@tomasMizera tomasMizera removed the FROZEN 🥶 do not merge before upcoming release label Jul 21, 2025
@Withalion Withalion force-pushed the move-to-project-ids branch from 61b99d1 to 9ab3d46 Compare July 24, 2025 14:52
@tomasMizera tomasMizera self-requested a review July 25, 2025 07:58
projectNamesToRequest.erase( projectNamesToRequest.begin() + listProjectsByNameApiLimit, projectNamesToRequest.end() );
Q_ASSERT( projectNamesToRequest.count() == listProjectsByNameApiLimit );
projectNamesToRequest.erase( projectNamesToRequest.begin() + maxProjectRequests, projectNamesToRequest.end() );
Q_ASSERT( projectNamesToRequest.count() == maxProjectRequests );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess

Suggested change
Q_ASSERT( projectNamesToRequest.count() == maxProjectRequests );
Q_ASSERT( projectNamesToRequest.count() <= maxProjectRequests );

Q_ASSERT( r == transaction.replyPullProjectInfo );

if ( r->error() == QNetworkReply::NoError )
{
QByteArray data = r->readAll();
const QByteArray data = r->readAll();
CoreUtils::log( "pull " + projectFullName, QStringLiteral( "Downloaded project info." ) );

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to compare if the server project ID is the same as the local project ID - in case remote project was renamed and some other project now bears the same name. We would try to sync a completely different project

@@ -2817,7 +2949,7 @@ void MerginApi::pushInfoReplyFinished()
transaction.replyPushProjectInfo->deleteLater();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to compare if the server project ID is the same as the local project ID - in case remote project was renamed and some other project now bears the same name. We would try to sync a completely different project

* \param isInitialPush indicates if this is first push of the project (project creation)
* \return true when sync has started, false otherwise (e.g. due to a missing authorization or invalid server)
*/
Q_INVOKABLE bool pushProject( const QString &projectNamespace, const QString &projectName, bool isInitialPush = false );
bool pushProject( const QString &projectFullName, const QString &projectId, bool isInitialPush = false );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and other API definitions should not need to accept both projectName and projectId. The ID should be enough - we can lookup the name via mLocalProjectsManager

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate to server project ids
3 participants