Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add db:metadata functions for handling of doc metadata #27

Open
zadean opened this issue Jan 4, 2020 · 0 comments
Open

Add db:metadata functions for handling of doc metadata #27

zadean opened this issue Jan 4, 2020 · 0 comments

Comments

@zadean
Copy link
Owner

zadean commented Jan 4, 2020

@grantmacken yes, the db:link is very similar to the atom media-link-entry.
The saving of the file would need to happen either with the file module, or could be done outside of xqerl in the OS.
The link is just a reference from URI to filename. Upon selecting the linked URI, it is deferenced and the file contents returned as a xs:base64Binary. It can be useful when the files shouldn't be saved in the DB, but rather updated from outside. Within an XQuery context, the file is read a maximum of once, and cached. Since files can change outside xqerl's locking system, this is the only way to keep it deterministic (which it must be).

As for ETags and other content types:
I think I'll add an optional $meta as map(xs:string, xs:string) parameter to db:put that allows saving custom metadata. Also I'll add a db:metadata function that will return said metadata about a given URI. This could then be used to set custom headers (or whatever information about the data).
There could be some values that are always set with binary and text types, such as etag, timestamp. For links, this data will be retrieved/calculated from the file itself.
The timestamp for XML is already in the DB and part of the document key.
This will also allow for saving text as csv, plain, json, or whatever. or XML as text/xml, application/xml, atom+, etc.

I may think about adding the $meta parameter to functions meant to get collections. It could then be used as a filter. Or maybe a custom uri-collection function that can be filtered in this way instead of calling db:meta on every entry.

Originally posted by @zadean in #25 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant