You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
@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 todb:put
that allows saving custom metadata. Also I'll add adb: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 customuri-collection
function that can be filtered in this way instead of callingdb:meta
on every entry.Originally posted by @zadean in #25 (comment)
The text was updated successfully, but these errors were encountered: