Conversation
notebook id is invariant for the lifetime of the notebook server, and is based on the *initial* name of the notebook. - If the notebook is renamed, its UUID will not change during this session, but it will have a new UUID in the next session. - If a notebook has the same initial name as another previously seen, it will get a random ID, guaranteeing no collisions.
avoids appending unnecessary 0 to initial Untitled and Copy names.
rather than forcing 'UntitledN' or '-CopyN'
moved from rename notebook, reused in: - new notebook (dashboard and menu bar) - rename notebook - copy notebook blacklist_re and test_notebook_name moved to utils as well, as they are only ever used in this one dialog.
|
Great, it will be nice to get this figured out. Originally, my thought was that we would use something persistent on disk (maybe a simple sqlite db) to persist the path+title <-> notebook id mapping. Do you view your approach as better (why?) or just a temporary fix until we can add disk persistence. |
|
I don't see a very strong reason to add persistence to disk - this is much lighter weight, and doesn't depend on filesystem state. Links would not be invariant across rename + server restart, but then again, that's not super reliable either, since it requires renames to be universally done via the notebook UI, and is still only invariant if the directory is never renamed. |
|
Let's wait on this one until we wade through the multidirectory notebook design. It may turn out that we do away form notebook ids all together. |
|
I think that's fair - we have to be super confident in the new URL scheme before eliminating notebook-ids, though. |
|
At this point our plan is to move to notebook name based URLs, so I am going to close this. If our plans change we can always reopen this one. |
2 participants
notebook id is invariant for the lifetime of the notebook server exactly as before, and is based on the initial name of the notebook.
during this session, but it will have a new UUID in the next session.
it will get a random ID, avoiding any collisions.
Currently, the user has no control over the initial names of notebooks, which means that even with this scheme, UUIDs are almost guaranteed to change from the session in which a notebook is created and the next. To address this, a 'name' argument is added to both the 'new notebook' and 'copy notebook' methods, and these actions now prompt for the name of the new notebook before creating them.
Be extremely careful testing this PR - the reason we haven't done persistent UUIDs before is our first attempt resulted in data loss, so we must be careful and rigorous here.