Re: WebDAV error using XMLMindEditor

On Tue, 2007-07-31 at 20:02 +0200, Dannes Wessels wrote:

> I have made quite a few changes -regarding webdav locking- in the
> past, these might by actually part of 1.0.x ; any way the most recent
> changes are part of the 1.1.x releases.

Hello Dannes,

I'll check it tonight! Many thanks!

> Please could you check the editor on the demo server?
> 
> http://demo.exist-db.org/webdav/db/ ?

There does not seem to be real files XXE could load?

http://museicapitolini.net/webdav/db/ there are ..

> Anyways, the current webdav implementation works very well with
> OxygenXML, XmlSpy, jEdit, XP webfolders so that gives us hope. At
> least for me 

At least for us! My problem is not so much myself as my colleagues, if
they can edit the files on the web server (or on an internal server)
they have immediate feedback if the editing is ok.

The higher up in command you go, the easier it has to be.

Many thanks, I'll report back tonight with a 1.1.x version!

Re: WebDAV error using XMLMindEditor

On Tue, 2007-07-31 at 20:02 +0200, Dannes Wessels wrote:

> I have made quite a few changes -regarding webdav locking- in the
> past, these might by actually part of 1.0.x ; any way the most recent
> changes are part of the 1.1.x releases.

Dear Dannes,

checked it now with eXist 1.1.2dev and same error again ... XXE cannot
get the proper lock status.

If you want to play with it, a free version of XXE is here:
http://www.xmlmind.com/xmleditor/download.shtml

You're right, Oxygen works flawlessly ...

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Exist-open mailing list
Exist-open <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: Sorting by relevance?

Thanks Pierrick. Can you tell me when do you expect to finish this
implementation? Thank you!

jiao

On 7/31/07, Pierrick Brihaye <pierrick.brihaye <at> free.fr> wrote:
> Hi,
>
> Dazhi Jiao a écrit :
>
> > Hi, I am just wondering if there is a way to sort documents based on
> > their relevance to the query, when using the fulltext extensions?
>
> No.
>
> But we are currently starting to implement the syntax and formal
> semantics of XQuery 1.0 and XPath 2.0 Full-Text 1.0 working draft
> (http://www.w3.org/TR/xquery-full-text/) which has "score variables".
>
> More on this later then.
>
> Cheers,
>
> p.b.
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.

A million "recursive" elements: feasible?

Hello,

We have an XML schema which allows elements of a certain type (say X)
to contain an arbitrary number of other elements of type X. Obviously
this results in documents with an arbitrarily complex recursive
structure of Xs. Each X has an id attribute. We need to be able to
perform quick lookups based on this id. Definition of "quick":
comparable to a relational database query with an indexed column as
its "WHERE" condition.

As one might guess from reading the subject, the upper limit of Xs has
been set to one million. Initial tests using eXist have produced
lookup times of around one minute for "only" 100,000 Xs. Are there any
ways to _drastically_ improve this in eXist, or is a structure like
this inherently too complicated for this data set size and performance
requirement?

I have read about user-defined range indexes in eXist, but if I
understood them correctly, they are not really applicable for this
situation(?)

Some details:
Computer: Intel 2.8 GHz, 2 GB, Windows XP
# of documents: 1
Data type of the id: integer in my tests so far, will be a string
conforming to a specific format in practice
Uniqueness of the id: has been unique in my tests, may not be in actuality

Oh, and even though I am asking with eXist specifically in mind,
speculation about XMLDBs in general regarding this type of data

R: R: R: R: delete item performance issue

>If I split in 100 sub-colletion, I would want to know if it is possible 
>to  preview  how much will be able to become this response time.

> X 100 ? I hope no !!

>No need to fear anything like this performance degredation. Remember that
in general, index entry creation/updating is 
>always more costly than index scanning.  And your *searches* involve
scanning only. Partitioning will reduce the cost 
>of the index rewriting that a whole-document deletion requires. There
should be no noticeable effect on retrieval and 
>matching times.

Unfortunately the forecasts have not been respected. 
My response time to a simple Xquery is gotten worse of forty times !

At this point I'm forced to think to change XML db because in my environment

Response time (update or search) are very important.

Can you help me to avoid that ?

-----Messaggio originale-----
Da: exist-open-bounces <at> lists.sourceforge.net
[mailto:exist-open-bounces <at> lists.sourceforge.net] Per conto di Michael
Beddow
Inviato: venerdì 20 luglio 2007 19.10
A: exist-open <at> lists.sourceforge.net
Oggetto: Re: [Exist-open] R: R: R: delete item performance issue

Re: A million "recursive" elements: feasible?

> I have read about user-defined range indexes in eXist, but if I
> understood them correctly, they are not really applicable for this
> situation(?)

You need a range index on the id or your query will take forever 

For best results, the current SVN trunk version has some new indexing
and query optimization features, which should reduce the id lookup to
a single index lookup. Create a collection configuration like the
following:

<collection xmlns="http://exist-db.org/collection-config/1.0">
    <index>
        <fulltext default="none" attributes="false">
        </fulltext>
        <create qname=" <at> id" type="xs:string"/>
    </index>
</collection>

and in conf.xml set enable-query-rewriting="yes". If that worked, a
query like //foo[ <at> id = "abc"] should be really fast.

You may not get exactly the same performance as with a relational db
(after all, XQuery is not SQL, there's a much higher complexity), but
it should not be too bad.

Wolfgang

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.

Re: R: R: R: R: delete item performance issue

> Unfortunately the forecasts have not been respected.
> My response time to a simple Xquery is gotten worse of forty times !

That's strange. Can you give me an example of a query you are trying?

Wolfgang

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

R: R: R: R: R: delete item performance issue

Yes of course, 

a little summary: 
I have 230 K documents distributed over 100 collection of about 2300
document each.
Any xml document is about 3kb and have about 100 xml tags in 4 level tree
depth.
In the example, tag t_200_f is a leaf.
I search on root collection contains my 100 child collections.
Partition algorithm is based on :

documents have an 13 decimal digits key (assigned by my application), the
latest
two determining partitions (00, 01, 02, ... 99)

My simplest query can be "/DocBook/Book/T_200[(T_200_f &= 'dickinson')]"

That on my previous db (one collection) return in about 2-3 seconds), but 
After partitioning responds in 100-120 seconds.

These response time are measured whith one user. What happens if more users 
go to search documents ?

--------------------------------------------
I'm thinking to integrate lucene indexing , you think can I obtain
significative 
Improvements ?

Very tanks

Re: R: R: R: R: R: delete item performance issue

Hi,

> That on my previous db (one collection) return in about 2-3 seconds), but
> After partitioning responds in 100-120 seconds.

I still don't understand why it gets that much slower with "only" 100
collections. You just send one query on the top-level collection and
not one query on every collection?

Well, if your test data is not confidential and can be zipped to <
50MB, send me a backup of it and a bunch of queries and I can have a
look at it.

Wolfgang

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: A million "recursive" elements: feasible?

Hi,

Wolfgang Meier a écrit :

> You need a range index on the id or your query will take forever 

Well, we might expect more problems here : such a deep level would 
require *huge* DLN node identifiers which could raise some problems just 
because of their length.

Handling such a recursivity in a structural index might be an 
interesting R&D project 

Cheers,

p.b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/