Hi Ryan,
I fixed this on github just now. Sorry for the delay.
I filed a bug also so engineering can take care of the server's copy.
-jh-
On Apr 14, 2011, at 3:23 PM, seme...@hotmail.com wrote:
> The following code throws this error: [1.0] XDMP-ATTRSEQ: (err:XQTY0024)
> $node/@* -- Attribute
A little late on this thread, but I think I can explain why the initial
predicate change (removing "/") didn't make much difference.
"/" in a predicate is interpreted as "root of the tree containing the
context node." That's true in both 1.0 and 1.0-ml. When a context node is
not defined, "/" thro
No, the thing to remember is that the default axis is child::, not self::
(.//foo)[1] returns the same nodes as descendant::foo[1] because it is a
syntactic shorthand for the following:
(./descendant-or-self::node()/child::foo)[1]
Similarly, (.//@foo)[1] is shorthand for:
(./descendant-or-self
At 2011-05-12 15:58 -0400, Mike Sokolov wrote:
>On 05/12/2011 02:52 PM, Evan Lenz wrote:
> > I think most beginners expect .//foo to be short for descendant::foo
> > (which I'm guessing is what you meant), especially since in examples
> > like that they return the exact same results. // is only a g
On 05/12/2011 02:52 PM, Evan Lenz wrote:
> I think most beginners expect .//foo to be short for descendant::foo
> (which I'm guessing is what you meant), especially since in examples
> like that they return the exact same results. // is only a gotcha when
> you start using positional predicate
Hi Gary,
Perhaps this tutorial is of help:
http://developer.marklogic.com/media/mluc11-talks/rewrite.pdf
There is plenty more reading material on http://developer.marklogic.com/. Have
a look around..
Kind regards,
Geert
Van: general-boun...@developer.marklogic.com
[mailto:general-boun...@dev
Thanks Gert!
That's a very interesting idea, and using 21st century technology J. I'm
still on the learning curve and can't find any docs on the MarkLogic Rest
API. Would you have a link handy?
Thanks again,
gary
From: general-boun...@developer.marklogic.com
[mailto:general-boun..
I think most beginners expect .//foo to be short for descendant::foo (which I'm
guessing is what you meant), especially since in examples like that they return
the exact same results. // is only a gotcha when you start using positional
predicates (so be suspicious whenever you see them together
Ok thanks Jason and everyone else. I know in my experience cts:search has been
much faster. The one page I mentioned earlier that used to take 6 secs, now
I've gotten it down to 0.188 on average, mostly due to changing out XPath
queries to be cts. I'm not exactly sure why, and I'm hearing that
I've always been baffled by this interpretation - thanks for explaining.
Doesn't it seem as if .//foo *should* mean "descendant-or-self::foo" ?
At least that is what every newcomer's interpretation seems to be. I
guess one can't change the spec if that's not the case.
If it did, then .//foo[
Let me try to answer the general question...
The thing to remember about cts:search is it's a controlled vocabulary. You
can only express constraints using cts:query constructs, and those constructs
were designed and defined by our engineering team with our indexes in mind.
XPath was designed
I appreciate the help, but I'll just note that this is really just to satisfy
my curiosity. I'm ok with my performance now, cuz I got my page time to 0.3
secs, down from 6 secs. But this is good for my learning so I appreciate it.
I am using 4.2-3.2. Did you mean xdmp:query-trace? Cuz I don't s
You can probably see the difference in query execution by comparing the output
from xdmp:plan() or the log output using cts:query-trace().
You should also mention which server release you are using.
-- Mike
On 12 May 2011, at 09:29 , seme...@hotmail.com wrote:
> Here are some queries that are
That one takes 0.038 secs, slightly faster than the 0.04 other XPath one.
But I'm really more interested in why the cts version performs better.
From: breinhol...@ldschurch.org
To: general@developer.marklogic.com
Date: Thu, 12 May 2011 10:43:39 -0600
Subject: Re: [MarkLogic Dev General] Why is c
You might try the moving the @key reference out of the filter like this:
fn:collection()/resource-bundle/resource/@key[. eq
$key]/..[fn:lang($lang-code)]
Putting the attribute name in the filter sometimes doesn't allow the XPath to
use an index for the query. Moving it to the p
Here are some queries that are similar to the code I was talking about.
XPath (0.04 secs)
xquery version '1.0-ml';
let $key := "mykey"
let $lang-code := "spa"
return
fn:collection()/resource-bundle/resource
[@key = $key]
[fn:lang($lang-code)]
cts (0.015 sec)
xquery version '1.0-ml';
l
I would echo what Kelly is saying, emphasizing the word "equivalent".
XPath has a contract to return things in document order. cts:search has a
contract to return things in relevance order. Depending on what you are doing,
one can be less work than another (for example, it can create some work
Equivalent XPath and cts:search expressions should perform the same. Can you
share an example, and what version you are using?
If they are equivalent and there is a performance difference, then there may be
a bug.
Kelly
Message: 5
Date: Thu, 12 May 2011 09:05:16 -0600
From: "seme...@hotmail.co
I have encountered situations where Xpath is faster than cts:search.. It
depends how the xpath has been constructed.. and how many results would the
xpath return. If your Xpath has '//' then that would definitely slow down.
On Thu, May 12, 2011 at 11:17 AM, seme...@hotmail.com
wrote:
> I mean
I mean in general. I've always heard that cts:search is almost always as fast
or faster than XPath. I'm finding that to be the case, and wondering why that
is the case in general.
From: breinhol...@ldschurch.org
To: general@developer.marklogic.com
Date: Thu, 12 May 2011 09:11:17 -0600
Subject:
Perhaps you could give us the XPath and the cts:search() code. It would make
it easier to diagnose.
- Keith
From: general-boun...@developer.marklogic.com
[mailto:general-boun...@developer.marklogic.com] On Behalf Of
seme...@hotmail.com
Sent: Thursday, May 12, 2011 9:05 AM
To: general@develope
I wrote awhile ago that I thought it was usually best to use search:search for
full text searching, cts:search for node selection out of the db, and XPath for
node selection within a document. I just ran into a situation that doing the
same query for nodes in the DB using cts:search was 6 times
Hi Gary,
There might be code around (someone in my company did some work on Java
connectors for MarkLogic Server), but it might be easier to access MarkLogic
Server through HTTP. I am doing so at home actually. It allows you to take a
more functional approach. Here is an example how someone use
I'm in the process of converting a Cocoon application to use MarkLogic as
its database. If there were more time I would look at moving away from
Cocoon and using MarkLogic pipelines but that's too much to tackle right
now.
Because of this I was wondering if anyone in this community might know
I think you may find this blog post helpful:
http://xquerywebappdev.wordpress.com/2010/08/27/xquery-pattern-date-formatter/
On Thu, May 12, 2011 at 4:51 AM, Abhishek53 S wrote:
>
> Hi All
>
> I have the date value stored into Marklogic as the long format (java date
> to long utility). Is ther
Hi All
I have the date value stored into Marklogic as the long format (java date
to long utility). Is there any way to convert the long date to marklogic
compatible date format.
Thanks in advance !
Abhishek Srivastav
Systems Engineer
Tata Consultancy Services
Cell:- +91-9883389968
Mailto: abhis
26 matches
Mail list logo
