cuba.File in DataspaceSession shows wrong file path on second load

[paulzierep]

This is a bit difficult to reproduce, since it requires a running DSMS server. The example shown uses the local docker version from the DSMS repo.

In the following example:

picture_file = '3.png'

with DataspaceSession(conn_text, connect_kwargs=connect_kwargs, dataspace_name=PRIVATE_DATASPACE_DB_NAME, file_destination="client_files") as session:
    wrapper = cuba.Wrapper(session=session)
    
    f2 = cuba.File(path=picture_file)

    wrapper.add(f2, rel=cuba.activeRelationship)
    wrapper.session.commit()

The file loaded shows the expected path of the file on the local machine.

with DataspaceSession(conn_text, connect_kwargs=connect_kwargs, dataspace_name=PRIVATE_DATASPACE_DB_NAME, file_destination="client_files") as session:
    wrapper = cuba.Wrapper(session=session)

    f2 = wrapper.get(f2.uid)
    print(f2.path)

>>> client_files/c2ec7e1db7b44ecbb34e930767d040dd-3.png

The second time the identical code is used the path is from the remote machine.

with DataspaceSession(conn_text, connect_kwargs=connect_kwargs, dataspace_name=PRIVATE_DATASPACE_DB_NAME, file_destination="client_files") as session:
    wrapper = cuba.Wrapper(session=session)

    f2 = wrapper.get(f2.uid)
    print(f2.path)

>>> /sqlite-db/user-file-uploads/c2ec7e1db7b44ecbb34e930767d040dd-3.png

After some digging is found, that if the actual file is not yet copied to file_destination the local path is shown, but if the file is already copied, e.g. calling the wrapper again, the remote path is shown.
I assume this is not intended behavior.

[kysrpex]

@paulzierep Thank you for the detailed bug report. I could reproduce the behaviour directly in the transport session, so I assume the problem is in that layer.

if the actual file is not yet copied to file_destination the local path is shown, but if the file is already copied, e.g. calling the wrapper again, the remote path is shown.

This was exactly the reason. The attribute path of the file CUDS object is unique (you just have one CUDS so just one attribute), but inherently we need it to take different values for the client and the server (which is somewhat hacky). This is achieved by setting the attribute to the server path when the file is received at the server's end, and setting it to the client's path when the file is received at the client's end. In such a way, the path on the server is always the server's path and the path on the client always the client's path.

However, when the client already has the file, the server detects this and does not send the file. The bug was that then the client does not "receive" any file, and thus the path of the CUDS object is not updated.

I have changed this (PR #667) so that the CUDS object's path gets updated for the client also in this case.