File metadata on storage adapters

[samvera]

File metadata on storage adapters

[escowles]

For other storage adapters, we could store them in a sidecar file. The other option would be to store them in the metadata store instead. I don't have a strong preference for one over the other, but it seems like the sidecar file would make the storage adapters more self-contained.

[tpendragon]

Right now the mime_type/filename are stored in the metadata store. It basically goes "Book -> FileSet -> FileNode -> FileInStorageAdapter"

[jcoyne]

@tpendragon it seems like we should be able to upload a file with no metadata. Does that imply that the model would have only id/mime_type/filename ?

[tpendragon]

@jcoyne Which model?

[jcoyne]

I guess that would be FileSet

[tpendragon]

So, I see a couple options.

1. Postcard -> FileSet -> FileNode('mime_type', 'filename', 'width', 'height') -> (via file_identifiers) FileInStorageAdapter('content')

2. Postcard -> FileSet -> FileInStorageAdapter('filename', 'mime_type', 'width', 'height') (Problem is disk-based here, how do we store that info? And we won't be able to query for properties of the file)

3. Postcard -> FileSet -> FileNode('width', 'height', 'filename', 'mime_type') -> FileInStorageAdapter('filename', 'mime_type')

Which do you see as best?

[jcoyne]

Could we have

Postcard -> FileSet -> FileNode -> AbstractMetadataNode

Where AbstractMetadataNode could be part of the StorageAdapter or part of the Persistence?

So the StorageAdapter::Disk could take a metadata_store as an argument (file based store or database)
So the StorageAdapter::Memory could take a metadata_store as an argument (memory based store or database)
and the StorageAdapter::Fedora would have a default metadata store of (fcr:metadata/HTTP headers)?

[tpendragon]

@jcoyne That could work! I'm not sure how to implement it though - if you have any ideas I'd like to see it

[tpendragon]

I mentioned this in another ticket:

I think the easy way to solve this is to:

1. Get rid of FileNode.
2. Add a metadata property to our File class
3. Require a metadata adapter as an initialization argument for our Disk storage adapter, so it knows where to store metadata.

[escowles]

Requiring a metadata adapter for storage adapters that don't support metadata natively sounds like a good solution to me. If we really wanted to store tech metadata in a sidecar file, we could make a metadata adapter to do that.