So this happened again overnight but I have more information now.
1) I had switched off UPDINDEX on some of the databases and one of these was
affected so this is not an UPDINDEX issue
2) I found that there was a hard crash of the JVM - which would account for why
many databases were left
Hi Tim,
For your first question, I think your example falls into what the spec calls
"funky looking" keys. See the 3rd bullet point example under
http://www.w3.org/TR/xquery-31/#id-lookup:
> funky / an appropriate lookup for a map with rather odd conventions for keys.
In other words, I think
Hi Constantine,
> Incidentally, BaseX is simply unbelievably fast at executing this – a
> million fragments clustered and written out to another DB in 16 seconds on a
> laptop. My congratulations on an amazing product.
Thanks!
> If I use the entire XML fragment as a grouping key, something like
> We are already using UUIDs for file names. However we want, for
> example, guaranteed uniqueness across text names contained in elements
> within documents of a collection.
I am not sure how "text names contained in elements" will be
represented in your data. If it’s stored in text or
Hello,
I'm testing some XQuery 3.1 features against a JSON-LD[1] document and had
a few questions. In the JSON-LD format, the "@" symbol has special
semantics in key names, but seems to cause problems with the 3.1 lookup
operator.
For example:
Thanks, Joe! I guess I'd glossed over the "funky" example ;-) Regarding the
arrow operator, I was wondering whether something like this was possible:
json-doc(" http://lae.princeton.edu/catalog/0bp35.jsonld;)("@context") =>
json-doc()("@context")
which throws an error: [XPST0003] Unexpected end
Hi Tim,
"Funky" made me chuckle too!
I tested your code with the closest thing at hand - a local build of
branch of Wolfgang Meier's eXist repo with support for the arrow
operator (https://github.com/wolfgangmm/exist/tree/feature/arrowop) -
and your code worked fine there. So my hunch is that
7 matches
Mail list logo
