Hi Will,
Everything you want to search exists in document fragments (not properties)
right?
What would happen if you switched in a different searchable-expression via
operator and state? The combined query is taken into account by faceting, but
the searchable-expression is not.
-m
On Oct
Micah,
I think I may have explained poorly. This is essentially what I'm doing -- Docs
are, generally, like this:
doc
search-meta/
p...citesearch-meta//cite.../p
section
p...citesearch-meta//cite.../p
...
/section
/doc
Searches operate over //doc by default, but if you add the
Will, if I can jump in I think your idea of using different QNames is the
right way to look at it.
Facets are built from range indexes, and range indexes contain lists of values
and fragment ids for a given QName. So if the query matches the fragment, the
facet will show all the values in
Yes, the whole purpose of fragment rules is to create more fragments. It isn't
necessarily a win for accurate estimate: accuracy could also get worse,
depending on your use cases.
But if the fragment counts didn't change, then the fragment root probably had
an error in its specification. Wrong
Thanks Mike, this is very helpful.
We store our XML per chapter, but fragment on /doc (typically 1st level
headings under chapter) in ML. I ran some numbers -- These are the values for
the number of characters in a /doc:
stats xmlns:xml=http://www.w3.org/XML/1998/namespace;
median1720/median
In general, the goal is to organize your documents so that they make sense as
standalone units for queries and updates. Based on those statistics, it looks
to me like you're in a pretty good place for that, already.
If your documents were 20x larger, and you had a strict separation between
Mike - This is great info.
Thanks,
Will
-Original Message-
From: general-boun...@developer.marklogic.com
[mailto:general-boun...@developer.marklogic.com] On Behalf Of Michael Blakeley
Sent: Tuesday, October 18, 2011 9:08 PM
To: General MarkLogic Developer Discussion
Subject: Re:
Hi Mike,
In what way does selecting a different range index influence the counts in this
case? I'd say you are still selecting the same doc fragments, so I'd expect the
counts to not change at all. Am I overlooking something? Or is the
search:search libray really using count, and not the
