Search code examples
iosyapdatabase

YapDatabaseRelationship does not update file path on rename


I am developing an iOS app that records audio and display it in table view with some meta data. For saving records i am using YapDatabase. By reading wiki i am able to save records and create edge between file and record. It is working as expected e.g if i delete the record the YapDatabaseRelation extension also delete the associated file with the record. Now if i rename the file and update its fileURL property then instead of updating it delete the file.

Currently to address this issue, i manually rename the file using file manager and then update its fileURL property. Am I missing something here?


Solution

  • i manually rename the file using file manager and then update its fileURL property

    This is the correct way to do it.

    YapDatabaseRelationship doesn't support any file operations except deleting linked files. If you're curious why, read on.

    The YapDatabaseRelationship extension cannot distinguish between:

    • "please rename this file for me"
    • "please delete the previous linked file, and link to this new path now"

    That is, all it sees is:

    • the edge you gave it before (filePathA)
    • the edge you gave it now (filePathB)

    It knows that the fileURL is different, and thus the edge has changed. So, from its perspective, the previous edge is now broken/deleted, and is to be replaced with the new edge. Thus it runs the delete rules for the broken edge, which is to delete filePathA.

    One could argue that the extension should be able to determine one's intention based on whether filePathB exists or not. But this isn't the case. Some developers will choose to create the database edge first, and then move the file into place afterwards. Why exactly?

    When working with both the file system (e.g. images on disk) and a database, you essentially have 2 separate atomic systems. For example, consider the following operation:

    1. write an image to the filesystem
    2. update the database to link to the image

    If the app crashes after step 1 has completed, but before step 2, then you may be "leaking" files in your app's Documents folder. However, if you performed the inverse (step 2, then step 1) then you'd be safer in the sense of not "leaking" files, but with the new problem that the database item may be pointing to a fileURL that isn't valid yet. Which may or may not be a problem. Some developers use the database to track items in the Cache folder, which they know may disappear at any time.

    I hope this clears up some confusion.