search

multinet-app / multinet-client

Multinet web client application
https://multinet-app.readthedocs.io
4 stars 3 forks source link

Users shouldn't be able to delete tables that are used in current networks #149

Closed JackWilb closed 3 years ago

JackWilb commented 3 years ago

After uploading a network, I'm able to delete the tables that are required for that network. That means the network is still there, but the data is technically gone

waxlamp commented 3 years ago

I'm not sure this should be disallowed. You might want to, for instance, replace a table by deleting it and uploading a new one, without wanting to delete and recreate the network around it. But in that case, we would want to have robust error messages explaining that a particular network's tables are missing, etc.

JackWilb commented 3 years ago

I thought that the networks in arango were built as references to the node tables. In that case, it wouldn't be possible to just drop a new network in.

This also says:

If you delete a vertex all edges referring to this vertex will be deleted too

waxlamp commented 3 years ago

I thought that the networks in arango were built as references to the node tables. In that case, it wouldn't be possible to just drop a new network in.

This also says:

If you delete a vertex all edges referring to this vertex will be deleted too

What this means is, if you delete a vertex from a vertex table, any graph queries involving edges that mention that vertex will be implicitly skipped. That is, arangodb graph objects maintain consistency subject to changes in the underlying data.

In particular, this means you can delete a table and reupload it, and the graph will not "notice" (of course, you have to maintain the original key values, since the edge table uses those to define the edges).

I carried out a manual test to check this out: I made a two-vertex graph with a single edge between them. The Arango graph visualization shows the expected graph. Then, if I delete the first vertex from the vertex table, the graph vis changes to just show the second vertex and no edges (even though I didn't delete the edge itself). Finally, I deleted the entire vertex table, then recreated it, using the original key values. Sure enough, the visualization shows the original two-vertex network again.

So I think this means that we should allow this type of data mutation in general; however, it does mean that certain assumptions we have made don't really apply anymore. One thing that occurs to me: if you were to upload a new vertex table, then attempt to add rows to the edge table referring to those new vertices, I don't think they would appear in the graph object unless we're able to update the graph object to include the new table in its list of vertex tables. My point is, if we do allow full mutation, we'll need to also perform some bookkeeping around these types of arango quirks.

waxlamp commented 3 years ago

We just had a meeting about this. What we concluded is that we will allow table deletion despite their use in any network objects. This is to allow flexibility in reshaping data as the workspace owner sees fit. It's worth noting that this arises because we have in fact moved away from our original idea of Multinet as having a static data model. To provide maximum flexibility, we'll need to allow for table deletion, table addition, and changes in the tables and nodes referred to be a network (via, e.g., PUT requests to its edge table).

All of this will require some extra logic in the API for ease of use and safety. Watch for individual issues to be filed to capture these. In the meantime, I'm closing this issue in favor of those yet-to-be-filed ones.

waxlamp commented 3 years ago

Actually just looks like one issue for now: https://github.com/multinet-app/multinet-api/issues/61