hello,
can we please get details regarding the architecture, UML diagrams, flow diagrams and other information that can help us get started on making modifications to the existing code. Also, any resources like tutorials, blogs etc which would help us understand the flow and structure of eXist will be appreciated.
Thankin you
-Regards,
Sneha Somanath

2011/2/1 Evgeny Gazdovsky <gazdovsky@...>
>
> and code: doc(""/db/xmldb:exist:///foo/bar"";) is working as well without
> any exception
> becouse relative document's URI ("xmldb:exist:///foo/bar"";) has valid
> scheme for XmldbURI!
>
Another question what is principal difference between
"/db/xmldb:exist:///foo/bar";
and "/db/aaa:bbb:///foo/bar"?
P.S. The code doc("/db/xmldb%3aexist%3a///foo/bar"") is working as well too
;).
--
Evgeny
>

2011/2/1 Pierrick Brihaye <pierrick.brihaye@...>
> Hi again,
>
> Le 01/02/2011 13:34, Evgeny Gazdovsky a écrit :
>
> > Is an exception really required?
> > I guess it is. IMHO, you shouldn't be able to create a document with
> > such a URI. That's where we should have an exception AFAIC :-)
> >
> >
> >
> > Why?
> >
> > new URI("/an:foo/an:bar") is working as well
>
> Just like I said, it shouldn't.
>
> > In the db the char ":" will be encoded (escaped).
>
> IMHO, it's just a bad solution. How would you handle document names in
> the XQuery ? Sometimes, they would be (internally) encoded, sometimes
> not. I think, this results in something which isn't strong enough...
>
>
Obviously as other non askii chars. As I see we can use both names encoded
and not encoded,
becouse name will be decoded before this code (for doc() or other xquery
function).
> > xs:anyURI("http://localhost:5550/an:form-generator/an:address-geography
> ")>
>
>
>
> I think it shouldn't.
>
>
But Saxon and java.net.URI<eclipse-javadoc:%E2%98%82=eXist-1.5dev/%5C/usr%5C/lib%5C/jvm%5C/java-6-openjdk%5C/jre%5C/lib%5C/rt.jar%3Cjava.net%28URI.class%E2%98%83URI>
.URI(String<eclipse-javadoc:%E2%98%82=eXist-1.5dev/%5C/usr%5C/lib%5C/jvm%5C/java-6-openjdk%5C/jre%5C/lib%5C/rt.jar%3Cjava.net%28URI.class%E2%98%83URI%7EURI%7ELjava.lang.String;%E2%98%82String>str)
are not thinkig so ;)
I want to discuss an exception's throw in a code,
not the question: "How would you handle document names in the XQuery ?".
This is another question, which has no relation to discussed issue.
--
Evgeny

Hi again,
Le 01/02/2011 13:34, Evgeny Gazdovsky a écrit :
> Is an exception really required?
> I guess it is. IMHO, you shouldn't be able to create a document with
> such a URI. That's where we should have an exception AFAIC :-)
>
>
>
> Why?
>
> new URI("/an:foo/an:bar") is working as well
Just like I said, it shouldn't.
> In the db the char ":" will be encoded (escaped).
IMHO, it's just a bad solution. How would you handle document names in
the XQuery ? Sometimes, they would be (internally) encoded, sometimes
not. I think, this results in something which isn't strong enough...
> Also code like
>
> xs:anyURI("http://localhost:5550/an:form-generator/an:address-geography")&gt;
> work as well too.
I think it shouldn't.
...
> Like, all are workin as well.
Workarounds... :-)
Cheers,
p.b.

Hi,
Le 01/02/2011 12:58, Evgeny Gazdovsky a écrit :
> So we can create the docs that contains ":" in the it's name. but can't
> use one like doc("/db/foo:bar.xml") or doc-available("/db/foo:bar.xml").
Honestly, what is the gain for such a URI ? Would you use it on your
file system if you ever could ?
> Can we close years for the URI's scheme?
Many years ago, I've introduced this XmldbURI class. My purposes were :
1) to ensure that a valid XmldbURI is used everywhere in eXist
2) to branch easily configurable resolvers
For performance problems (at least on that time's JDKs), work has
stopped and I have tried to comment every use of URIs processed as...
Strings nearly everywhere in eXist. There is still much work to be done
in this area.
A little bit after, someone contributed a *huge* patch wich XmldbURI
rewriting whose rationale I can't understand. That made me definitively
stop my efforts in the XmldbURI area :-)
Since then, we've had no contribution at all on this class.
> Is an exception really required?
I guess it is. IMHO, you shouldn't be able to create a document with
such a URI. That's where we should have an exception AFAIC :-)
Cheers,
p.b.

Hello!
Just we have next code in the XmldbURI.java (lines 111-121):
boolean hadXmldbPrefix = false;
>
> if( xmldbURI.getScheme() != null ) {
>
> if( !XMLDB_SCHEME.equals( xmldbURI.getScheme() ) ) {
> throw( new URISyntaxException( xmldbURI.toString(), "xmldb
> URI scheme does not start with " + XMLDB_URI_PREFIX ) );
> }
> xmldbURI = new URI( xmldbURI.toString().substring(
> XMLDB_URI_PREFIX.length() ) );
> hadXmldbPrefix = true;
> }
> parseURI( xmldbURI, hadXmldbPrefix );
>
So we can create the docs that contains ":" in the it's name. but can't use
one like doc("/db/foo:bar.xml") or doc-available("/db/foo:bar.xml").
Becouse the part "foo:bar" have scheme "foo" that not equals to "xmldb".
But in same time "foo:bar" is not full path of URI, but is subpart.
Can we close years for the URI's scheme?
Is an exception really required?
--
Evgeny

Hi Joe,
No, the optimizer does not handle this (yet). We should indeed add it to the
tuning guide.
Wolfgang
Am 31.01.2011 13:29 schrieb "Joe Wicentowski" <joewiz@...>:
> Wolfgang,
>
> Gary's e-mail had me searching the archives, and I came across this
> interesting point you raised:
>
> On Tue, Dec 15, 2009 at 5:00 PM, Wolfgang Meier <wolfgang@...>
wrote:
>>>> Note that using subsequence instead of the predicate can be a lot
>>>> faster sometimes.
>>>
>>> I didn't realize that. Can you generalize about when subsequence
>>> would be faster? And would you say it's always at least as fast as
>>> the predicate?
>>
>> Mike used position() within the predicate: [position() = (1 to 10)].
>> This will indeed be slower than a corresponding subsequence($input, 1,
>> 10). Reason: the predicate has to be evaluated once for every item in
>> the context sequence. This doesn't make a big difference if you have a
>> simple expression like $a[position() = (1 to 10)], but it could result
>> in a substantial performance loss for more complex expressions
>> involving a path expression like a//*/b[position() = (1 to 10)].
>>
>> To be on the safe side, I would recommend subsequence() if you need to
>> select *more than one* item.
>
> To confirm, is this still the case? Or is the query optimizer now
> taking care of this case?
>
> If it is still the case, it seems to me this would really be worth
> adding to the Performance Tuning article - do you agree?
>
> Thanks,
> Joe

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details