Skip to content

Conversation

@mrtcode
Copy link
Member

@mrtcode mrtcode commented May 30, 2017

A prototype of the file identifier. Currently supports identifying files by hash.

File item itself doesn't have file metadata. Instead, itemAttachments table is required to resolve sourceItemID and the actual item that has the file metadata. itemAttachments also has storageHash column which - for simplicity reasons - is used in this prototype to query required items. But it needs to create an index. Another option is to query through storageFileItems table with storafeFileID.

This prototype is querying by library.

Because file item can be nested to any other item, this can result in incorrect metadata. Therefore more libraries should be used to evaluate results. But probably no need to scan too many libraries.

Looking in future, maybe the file identifier should have its own controller if it's going to use full text data. E.g.: IdentifierController.

It's probably convenient to use specific rate limiters in different controllers than the global rate limiter in ApiController.

The result looks like:

{
    "identifiers": {
        "ISSN": [
            "1935-990X, 0003-066X"
        ],
        "DOI": [
            "10.1037/0003-066X.59.1.29"
        ]
    }
}

@mrtcode
Copy link
Member Author

mrtcode commented May 31, 2017

Dataserver ApiControler prohibits any write requests if there isn't a key or session or it's not a '/keys' requests. The error message is 'An API key is required for write requests.'. All controllers extend ApiController therefore they can't accept anonymous POST requests. File identifier is a public API that needs to accept JSON POST request. Do we need to modify ApiController or create another controller that doesn't extend ApiController?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant