[needs-doc] Add stable id, save id, save count to project spec #6527

NathanW2 · 2018-03-05T04:11:10Z

Adds some new metadata about the project itself for future use.

<qgis version="2.99.0-Master" save-counter="7" projectname="" save-user-full="Nathan" id="3ed6e416-b659-455d-a870-99971197890" save-id="64e96782-d2aa-4350-b2f6-7e77f31eece" save-user="nathan">

Adds the following information:

id() -> Stable ID that never changes (can be used to track the project even if the file name changes)
saveId() -> Changes on each save to give you a ID number for that version
saveCounter() -> A int with a counter how many times this project has been saved. Same kind of deal as saveId() but we will have both anyway
saveUser() -> Last saved user
saveUserFull -> Last saved user full name.

NOTE: I was considering backporting this into 3.0 so that we can start getting projects including those ids for future release. If you save with a older version of QGIS it will nuke these values.

NathanW2 · 2018-03-05T04:19:38Z

Some background on why this might be a good idea. I would like to generate preview images for each project that is opened so I can use them in tooltips, however I have no stable ID I can use for filenames. This would provide that and would allow for moving the projects around but keeping the previews.

Another user for id() and saveId() is a possible future saving of projects in database or web server. Using these two ids we can track if a project has changed on the server by someone else etc. Would also allow backends to implement versioning around project save without making their own ids.

nyalldawson · 2018-03-05T04:30:06Z

src/core/qgsproject.cpp

+static QString generateUuid()
+{
+  QString uuid = QUuid::createUuid().toString();
+  return uuid.mid( 1, uuid.length() - 3 );


off topic - but wow it annoys me the format QUuid uses.

You and be both. Never once have I thought "man I wish this guid had { } around it". Silly.

nyalldawson · 2018-03-05T04:31:55Z

src/core/qgsproject.h

+    QString mSaveId;              // changing id for each save.
+    QString mSaveUser;              // last saved user.
+    QString mSaveUserFull;              // last saved user.
+    int mSaveCounter;              // increasing save counter


initialize to 0 here

NathanW2 · 2018-03-05T06:11:18Z

@nirvn @m-kuhn @wonder-sk how do you feel about these?

wonder-sk · 2018-03-05T16:27:56Z

I think it is a bit tricky with the IDs... if I have an existing project and use save-as to make a copy and modify that project afterwards, I would end up with both original and the new project sharing the same ID right?

And how would we use saveCounter()?

nyalldawson · 2018-03-05T23:39:18Z

I think it is a bit tricky with the IDs... if I have an existing project and use save-as to make a copy and modify that project afterwards, I would end up with both original and the new project sharing the same ID right?

Yes - that's the purpose of the persistent id -- it would allow tracking of project "forks" like this. The saveId() will be regenerated though and will be new.

NathanW2 · 2018-03-05T23:56:20Z

Hmm Martins point is valid if I wanted to use the id() to assign generate a thumbnail using just that. The thumbnail is a minor thing I can think about later so I still think it's valid to have these ids.

…

On Tue, Mar 6, 2018 at 9:39 AM, Nyall Dawson ***@***.***> wrote: I think it is a bit tricky with the IDs... if I have an existing project and use save-as to make a copy and modify that project afterwards, I would end up with both original and the new project sharing the same ID right? Yes - that's the purpose of the persistent id -- it would allow tracking of project "forks" like this. The saveId() will be regenerated though and will be new. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3OwZHu-7FatT1PHaiMBjc5NfLjWtks5tbcyngaJpZM4Sbs65> .

nyalldawson · 2018-03-06T00:32:45Z

Hmm Martins point is valid if I wanted to use the id() to assign generate a
thumbnail using just that.

Wouldn't you use saveId() for that? Otherwise you'd see an outdated thumbnail.

so I still think it's valid to have these ids.

Very much so! I can see lots of potential use for them, and the sooner they start to be recorded in projects the better...

NathanW2 · 2018-03-06T00:58:21Z

Yeah i guess we can use save id and just delete the old one after each save. That is a good point.

…

On Tue, 6 Mar. 2018, 10:32 am Nyall Dawson, ***@***.***> wrote: Hmm Martins point is valid if I wanted to use the id() to assign generate a thumbnail using just that. Wouldn't you use saveId() for that? Otherwise you'd see an outdated thumbnail. so I still think it's valid to have these ids. Very much so! I can see lots of potential use for them, and the sooner they start to be recorded in projects the better... — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3D10dCsWp64hwr1-ZRaxlvXhzrcUks5tbdkugaJpZM4Sbs65> .

nyalldawson · 2018-03-06T01:07:38Z

Yeah i guess we can use save id and just delete the old one after each
save. That is a good point.

Doesn't that break to "save as" case though? E.g. open existing project, save as => original project thumbnail is deleted.

NathanW2 · 2018-03-06T01:09:17Z

Thumbnails will be generated on load anyway so you will get it back right away.

m-kuhn · 2018-03-06T03:09:01Z

What about saving the thumbnail straight into the project file?

nirvn · 2018-03-06T03:10:55Z

@m-kuhn , that's what I suggested (off github) yesterday. IMHO, that's what makes the most sense on the longer term.

NathanW2 · 2018-03-06T03:11:58Z

I thought about that however the downside is that we need to load and parse the xml for each project in the browser tree which might be slow over networks.

…

On Tue, Mar 6, 2018 at 1:09 PM, Matthias Kuhn ***@***.***> wrote: What about saving the thumbnail straight into the project file? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3Pe8mBxZOFg2uw8UDaCUSjXkH15dks5tbf3OgaJpZM4Sbs65> .

NathanW2 · 2018-03-06T03:15:39Z

Is everyone ok with this id idea though so that we could use it for other things? In theory keeping the id() stable even if you copy the project is not a bad things (unless you do Save As in which case I will change it). If you combine savecounter + path + id() you can see if two projects files are the same and if they have changed over time e.g C:\temp\project.qgs ID1 Count3 C:\temp\project-copy.qgs ID1 Count7

m-kuhn · 2018-03-06T04:17:29Z

I thought about that however the downside is that we need to load and parse the xml for each project in the browser tree which might be slow over networks.

Isn't that the same with the metadata in discussion here?

NathanW2 · 2018-03-06T04:24:49Z

haha good point. Never mind then :) *headdesk* So maybe we will just store them in the project file as base64. I would still like to see this ID stuff implemented for other future uses though.

…

On Tue, Mar 6, 2018 at 2:17 PM, Matthias Kuhn ***@***.***> wrote: I thought about that however the downside is that we need to load and parse the xml for each project in the browser tree which might be slow over networks. Isn't that the same with the metadata in discussion here? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3EL9a55YXV7m7vw2O5DFTjzlHFOyks5tbg3agaJpZM4Sbs65> .

m-kuhn · 2018-03-06T04:25:57Z

So maybe we will just store them in the project file as base64

can we go for qgd and ship it binary?

NathanW2 · 2018-03-06T04:29:41Z

Possible. I know there has been talk about just swapping to qgz as the default format. I'm unsure how I feel about that yet but if we do I'm ok putting into qgd. Putting projects inside qgz also might raise network issues. Nyall thoughts?

…

On Tue, Mar 6, 2018 at 2:25 PM, Matthias Kuhn ***@***.***> wrote: So maybe we will just store them in the project file as base64 can we go for qgd and ship it binary? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6527 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3NeisB5D9Fpg3okoXaqmxoLYJiBQks5tbg_WgaJpZM4Sbs65> .

NathanW2 · 2018-03-11T23:02:14Z

So any thoughts on this logic? Even if we go with a qgz default format in future I still think having this logic in the project would be handy for tracking or other uses.

nyalldawson · 2018-03-11T23:11:56Z

So any thoughts on this logic? Even if we go with a qgz default format in future I still think having this logic in the project would be handy for tracking or other uses.

I'm +1. Obviously it has limitations, but I'd still find it super-useful.

The only improvement I can think of is adding (yet another) uuid - so we have:

original project id: created on new project, never changed, regardless of how the project is branched or modified.
unique project id: created on new project and reset when doing a "save as".
project version id: recreated on every save

m-kuhn · 2018-03-12T00:11:39Z

So any thoughts on this logic?

I don't see any big downsides. One shouldn't blindly trust it, but if it's useful for something, go ahead. I can't see a better approach nor any risks.

NathanW2 · 2018-03-12T04:09:45Z

@wonder-sk your thoughts?

wonder-sk · 2018-03-12T15:08:50Z

I think I am still confused about how all this would be used and what expectations developers can have from these new values:

id() aka "stable id" aka "original project id" - if a user modifies prj1 and saves it as prj2, we still keep the ID untouched. I think this my main source of confusion: by having two different projects - prj1 and prj2 - how useful is the information for us that at some point the two projects were started from the same base project, but at this point they may be completely unrelated?
id() [take two]: I am bit afraid of introducing a situation we had with layer IDs where in multi-project environment we could have different layers with the same IDs present - but this time with project IDs. There could easily be confusion that some plugins will think that id() returns a unique value for each loaded project, which is not true (and e.g. have a dictionary where project IDs would be used as keys).
saveId(): agreed this may be useful. (Even though often project filename + last modified timestamp is good enough as a unique project identifier - but yes, saveId() would survive project file moves/copies while filename+timestamp would not.)
saveCounter(): here I am confused again where could we use it - it seems to me it does not really add any new information compared to saveId() since two different projects with the same id() that diverged over time can have arbitrary relationship between counters. Having prj1 and prj2 with the same id() and with prj1 counter = 10 and prj2 counter = 11, we still cannot imply anything - prj1 and prj2 may have diverged at counter = 3, so prj1 cannot be considered as a previous version of prj2. If we ever need to somehow compare versions of projects, their timestamp seems like the best option.
the "unique project id" as suggested by Nyall may not necessarily help the whole situation either - if a user copies a project in file browser, the unique project id would still stay the same although the two projects may diverge.

By the way... recently at Lutra we have been tasked to add support for loading/saving projects in PostgreSQL database. In a couple of days Peter or me should get back with a QEP discussing that.

nyalldawson · 2018-06-28T00:24:01Z

Ping @probot

stale · 2018-07-12T01:15:43Z

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

that all unit tests are passing
that all comments by reviewers have been addressed
that there is enough information for reviewers, in particular
- link to any issues which this pull request fixes
- add a description of workflows which this pull request fixes
- add screenshots if applicable
that you have written unit tests where possible
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
If there is no further activity on this pull request, it will be closed in a week.

stale · 2018-07-19T01:38:42Z

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist.

thbaumann · 2020-01-16T08:28:45Z

Hi @NathanW2: I picked up your idea of adding the username to the QGIS project file in my pullrequest 33843. Do you think it is pointed out enough that the code snippets were originally written by you or do you have any suggestions?

[needs-doc] Add stable id, save id, save count to project spec

a33ae11

NathanW2 requested a review from nyalldawson March 5, 2018 04:11

NathanW2 self-assigned this Mar 5, 2018

NathanW2 added Feature 3.2 labels Mar 5, 2018

Move debug info

efef518

nyalldawson reviewed Mar 5, 2018

View reviewed changes

Init mSaveCounter to 0

28f58f1

3nids added this to the 3.2 milestone Mar 14, 2018

3nids removed the 3.2 label Mar 14, 2018

wonder-sk mentioned this pull request Mar 20, 2018

Projects in PostgreSQL qgis/QGIS-Enhancement-Proposals#118

Closed

nyalldawson added the 3.4 label May 29, 2018

m-kuhn modified the milestones: 3.2, 3.4 May 31, 2018

nyalldawson removed the 3.4 label Jun 10, 2018

qgis deleted a comment from SamirSuhib Jun 22, 2018

nyalldawson added the Requires Changes! Waiting on the submitter to make requested changes label Jun 22, 2018

stale bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jul 12, 2018

stale bot closed this Jul 19, 2018

thbaumann mentioned this pull request Jan 16, 2020

add userLoginName and userFullName to QGIS project when writing the p… #33843

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[needs-doc] Add stable id, save id, save count to project spec #6527

[needs-doc] Add stable id, save id, save count to project spec #6527

NathanW2 commented Mar 5, 2018 •

edited

Loading

NathanW2 commented Mar 5, 2018

nyalldawson Mar 5, 2018

NathanW2 Mar 5, 2018

nyalldawson Mar 5, 2018

NathanW2 Mar 5, 2018

NathanW2 commented Mar 5, 2018

wonder-sk commented Mar 5, 2018

nyalldawson commented Mar 5, 2018

NathanW2 commented Mar 5, 2018 via email

nyalldawson commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

nyalldawson commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

m-kuhn commented Mar 6, 2018

nirvn commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

NathanW2 commented Mar 6, 2018 via email

m-kuhn commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

m-kuhn commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

NathanW2 commented Mar 11, 2018

nyalldawson commented Mar 11, 2018

m-kuhn commented Mar 12, 2018

NathanW2 commented Mar 12, 2018

wonder-sk commented Mar 12, 2018

nyalldawson commented Jun 28, 2018

stale bot commented Jul 12, 2018

stale bot commented Jul 19, 2018

thbaumann commented Jan 16, 2020

[needs-doc] Add stable id, save id, save count to project spec #6527

[needs-doc] Add stable id, save id, save count to project spec #6527

Conversation

NathanW2 commented Mar 5, 2018 • edited Loading

NathanW2 commented Mar 5, 2018

nyalldawson Mar 5, 2018

Choose a reason for hiding this comment

NathanW2 Mar 5, 2018

Choose a reason for hiding this comment

nyalldawson Mar 5, 2018

Choose a reason for hiding this comment

NathanW2 Mar 5, 2018

Choose a reason for hiding this comment

NathanW2 commented Mar 5, 2018

wonder-sk commented Mar 5, 2018

nyalldawson commented Mar 5, 2018

NathanW2 commented Mar 5, 2018 via email

nyalldawson commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

nyalldawson commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

m-kuhn commented Mar 6, 2018

nirvn commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

NathanW2 commented Mar 6, 2018 via email

m-kuhn commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

m-kuhn commented Mar 6, 2018

NathanW2 commented Mar 6, 2018 via email

NathanW2 commented Mar 11, 2018

nyalldawson commented Mar 11, 2018

m-kuhn commented Mar 12, 2018

NathanW2 commented Mar 12, 2018

wonder-sk commented Mar 12, 2018

nyalldawson commented Jun 28, 2018

stale bot commented Jul 12, 2018

stale bot commented Jul 19, 2018

thbaumann commented Jan 16, 2020

NathanW2 commented Mar 5, 2018 •

edited

Loading