This is an excerpt of my business object class diagram (go fixed font
size):
[MyObject]
|
0..* |
V parent
[Namespace]<>--+
|0..1 |
| 0..*|
+-+
child
All business object instances have a unique identifier.
A namespace path
: This is the simplest thing I could think of:
:
: * store full namespace path as one term: "1/2/3"
: * store each namespace identity as on term: "1", "2", "3"
I use the second approach for finding all Docs at a given node or below in
the tree ... instead of the first appraoch, have a field w
25 nov 2006 kl. 04.19 skrev Chris Hostetter:
: This is the simplest thing I could think of:
:
: * store full namespace path as one term: "1/2/3"
: * store each namespace identity as on term: "1", "2", "3"
I use the second approach for finding all Docs at a given node or
below in
the tr
: There is however virtually no cost for me to calculate the full path,
: so I might just experiment with the span query thingy.
if you odn't mind using a span, then just reverse the ordering so the
"leaf" that the docs are at appear in the first position -- then you can
use a SpanFirst to check
25 nov 2006 kl. 17.12 skrev Chris Hostetter:
personally ... i'd rather have a slightly bigger index then slightly
slower queries.
Me too, usually. But I'm running this in my alternative RAM index, so
it should be OK. That is also the reason to why I want to save thoses
bytes. But again, t
Hi,
Just noticed this thread and don't know if this has been mentioned. What
I do is add a 'path' field with the xpath to the node. Then you first
narrow your search by finding documents with paths like:
/node[1]/node[3]*
best,
-Rob
karl wettin wrote:
25 nov 2006 kl. 17.12 skrev Chris Hos
25 nov 2006 kl. 17.26 skrev Robert Koberg:
What I do is add a 'path' field with the xpath to the node. Then
you first narrow your search by finding documents with paths like:
/node[1]/node[3]*
You use a wildcard query? That can turn out to be very expensive if
you have a thousand and tho
karl wettin wrote:
25 nov 2006 kl. 17.26 skrev Robert Koberg:
What I do is add a 'path' field with the xpath to the node. Then you
first narrow your search by finding documents with paths like:
/node[1]/node[3]*
You use a wildcard query? That can turn out to be very expensive if you
have
