Thanks Mike.
Could you tell me the exact use for point in time queries besides fores
rollover.
On 1 Oct 2014 20:48, Michael Blakeley m...@blakeley.com wrote:
You don't, not using point-in-time queries.
It sounds like you want version control rather than point-in-time. Take a
look at DLS:
I realise this is more of an xquery question but everyone here is stumped :-s
I have a query that is trying to calculate some earliest and latest dates that
an event occurred. The events are represented in xml like this:
publication
Hi Rachel,
The order by clause is type-aware. You example orders by the data() value of
the provided element (which will be xs:string unless a schema is in scope). You
should construct an xs:dateTime and order by that:
order by xs:dateTime($x/publicationDateTime)
It's also worth noting that
I can't add much to https://docs.marklogic.com/guide/app-dev/point_in_time
Some applications use point in time queries for content staging purposes.
Production queries run at a known timestamp T. Meanwhile updates continue to
arrive, but they are invisible to production queries because they are
The order of operations in a FLWOR isn't guaranteed. The return expression
could be evaluated before the sorting is done.
You might also be interested to know that maps are unordered. So you can put
those items into the map in any order you like, but the keys will end up in
whatever internal
That is not necessary, because an untyped simple element will atomize as
xs:untypedAtomic and then sort as a string. The string representation of an
xs:dateTime orders exactly like an xs:dateTime.
Try it.
-- Mike
On 2 Oct 2014, at 09:34 , Joe Bryan joe.br...@marklogic.com wrote:
Hi Rachel,
HI.
For the sample given, you can also just pack it all in a single sequence
where the odd numbered indexes are the content dates and the even numbered
indexes are the dates.
Then a few of the sequence related access functions
Iteration is then just done on the odd numbers, etc,.
If you use the
Hi jb,
Ah yes, I was aware of that one having being bitten by it before :) But in
this case it doesn't make sense because even as strings they'd be ordered
correctly, no?
From: Joe Bryan joe.br...@marklogic.commailto:joe.br...@marklogic.com
Reply-To: MarkLogic Developer Discussion
Thanks Mike,
Are you saying never to do anything in the return statement that depends
on the order - that the order by clause only orders the final results.
It's so surprising because it does *mostly* work, until I added the order
by clause it was *completely* wrong. And it's worked fine for
Wow! I'm new to functional thinking and I can't quite imagine that :) but am
looking forward to coming back to this question in a year's time and redoing it
From: David Ennis david.en...@hinttech.commailto:david.en...@hinttech.com
Reply-To: MarkLogic Developer Discussion
I have a simple document ...
root
sourceId53067/sourceId
sourceNameDB1/sourceName
titleRMS7799/title
contentSome content which should not be searched for and shown in
results/content
contentWithoutMarkupthis is the original story which needs to be
found/contentWithoutMarkup
/root
i have
I try not to rely on evaluation order anywhere, if I can help it. But I'm not
sure whether MarkLogic's behavior matches the spec or not.
According to http://www.w3.org/TR/xquery/#id-orderby-return the resulting
order determines the order in which the return clause is evaluated.
I like tests,
If I understand your use-case correctly, you want a word-query exclude:
https://docs.marklogic.com/guide/admin/wordquery
Phrase-around is for phrase control:
https://docs.marklogic.com/guide/admin/text_index#id_29138
-- Mike
On 2 Oct 2014, at 12:05 , Girish Kulkarni girishbkulka...@gmail.com
Hi,
We have a requirement whereby if a full-text search query matches a word in
the title element, we want it to get a weight of 100, but if it's in the
body element, then weight should be 50.
Is this the correct way to do it in the OPTIONS argument for search:search ?
term
Hi,
We have article documents, each of which has a corresponding descriptor
document that contains key elements from the its parent article, but
structured differently for easier searching.
All the articles are stored under the articles directory and all the
descriptor docs in the descriptors
Not knowing anything else about your app, this sounds like a good use case for
the “envelope” pattern. Rather than separate article…/article and
descriptor…/descriptor documents, you can combine them into something like
ns:envelope
descriptor…/descriptor
article…/article
/ns:envelope
You
16 matches
Mail list logo
