Open
Description
Description
Switching file ID managers from e.g. LocalFileIdManager to ArbitraryFileIdManager doesn't play well with the database:
HTTPServerRequest(protocol='http', host='127.0.0.1:8888', method='GET', uri='/api/yjs/roomid/Untitled.ipynb?1666790876574', version='HTTP/1.1', remote_ip='127.0.0.1')
Traceback (most recent call last):
File "/home/david/mambaforge/envs/jupyterlab/lib/python3.10/site-packages/tornado/web.py", line 1713, in _execute
result = await result
File "/home/david/github/davidbrochart/jupyter_server_ydoc/jupyter_server_ydoc/ydoc.py", line 310, in get
idx = file_id_manager.index(path)
File "/home/david/github/davidbrochart/jupyter_server_fileid/jupyter_server_fileid/manager.py", line 138, in index
cursor = self.con.execute("INSERT INTO Files (path) VALUES (?)", (path,))
sqlite3.IntegrityError: NOT NULL constraint failed: Files.ino
Reproduce
- Run JupyterLab in collaborative mode and
LocalFileIdManagerinstalled, and open a file. - Run again JupyterLab with an
ArbitraryFileIdManager, and open the file. - See the error above.
Expected behavior
Should we use a different database when switching file ID managers? If yes, this issue can be closed.
Otherwise, I'm not sure we should have filesystem-specific attributes in the database. I understand it is needed for local filesystems, but maybe we should give it a more abstract name? In the end, it is some kind of identifier. And other file ID managers might not have this notion, so maybe we should allow it to be NULL?