Re: Storing complex documents in eXist

Hi,

If you followed the recent discussion about numbering schemes and indexing on 
this list, you will probably know that we are thinking about replacing the 
current indexing scheme and its limitations with one of the proposed 
alternatives. The plan is to first refactor some of the classes and methods 
that depend on the numbering scheme and then to implement and test one of the 
alternative schemes. 

I have the ok of my boss to spend a few weeks in October to work on this 
issue.

Wolfgang


> Hello all,
> I've got a problem - we're developing web shop application with use of
> eXist and one of our shops has very complex structure - over 170 product
> categories and about 1600 products in them. When trying to upload this xml
> file to eXist, I've got error:
>
> 29 ╤Б╨╡╨╜ 2004 10:35:36,125 [Thread-5] DEBUG (LocalCollection.java
> [storeResource]:530) - storing document store.xml 29 ╤Б╨╡╨╜ 2004
> 10:35:36,156 [Thread-5] DEBUG (Collection.java
> [determineTreeStructure]:1112) - validating document store.xml
> org.exist.EXistException: The document is too complex/irregularily
> structured to be mapped into eXist's numbering scheme. Number of children
> per level of the tree: [ 1, 3, 16, 7, 25, 17, 26, 17, 13, 17, 14, 17, 15,
> 17, 11, 17, 13, 17, 10, 17, 15, 17, 7, 2 ]
>
>         at
> org.exist.dom.DocumentImpl.calculateTreeLevelStartPoints(DocumentImpl.java:
>263) at
> org.exist.dom.DocumentImpl.calculateTreeLevelStartPoints(DocumentImpl.java:
>248) at
> org.exist.collections.Collection.determineTreeStructure(Collection.java:111
>9) at org.exist.collections.Collection.validate(Collection.java:778) at
> org.exist.xmldb.LocalCollection.storeXMLResource(LocalCollection.java:586)
> at org.exist.xmldb.LocalCollection.storeResource(LocalCollection.java:531)
> at org.exist.client.InteractiveClient.parse(InteractiveClient.java:1539) at
> org.exist.client.ClientFrame$37.run(ClientFrame.java:972)
>
> I've found this: "However, there are some documents with a very irregular
> structure, which cannot be mapped into the internal identifer scheme. Such
> documents have to be split into smaller, logical parts. We are working on
> an automatic splitting algorithm to simplify this." at
> http://exist.sourceforge.net/facts.html, but I'd like to know if there's
> insuperable obstacle or there's a way to turn around this limitation. If
> there's no way currently to avoid this constraint, is there any chance that
> the situation will change in a forseeable future?


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl