semi-persistent notebook IDs #3140

Closed
wants to merge 5 commits into
from

Projects

None yet

2 participants

@minrk
Owner
minrk commented Apr 6, 2013

notebook id is invariant for the lifetime of the notebook server exactly as before, 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, 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.

minrk added some commits Apr 6, 2013
@minrk minrk add persistent notebook UUIDs
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.
20c85d2
@minrk minrk filenb increment starts with base file
avoids appending unnecessary 0 to initial Untitled and Copy names.
fd49d1b
@minrk minrk accept 'name' argument to new / copy
rather than forcing 'UntitledN' or '-CopyN'
6e9af44
@minrk minrk expose name argument over copy/new handlers 19782f8
@minrk minrk add central 'notebook name' dialog to utils
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.
0bea430
Owner

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.

Owner
minrk commented Apr 6, 2013

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.

Owner

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.

Owner
minrk commented Apr 13, 2013

I think that's fair - we have to be super confident in the new URL scheme before eliminating notebook-ids, though.

Owner

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.

@ellisonbg ellisonbg closed this Apr 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment