Database Reference
In-Depth Information
10. Either an afterCreateDocument or an afterUpdateDocument event is raised with
each document trigger configured on the target collection.
Binary Document Storage
When given a binary document (i.e., any document that is not XML), eXist stores a
copy of it in a shadow of its collection hierarchy on disk under the folder
$EXIST_HOME/webapp/WEB-INF/data/fs ; it also stores a copy of the document
metadata (e.g., database permissions, owner, group, and created date) into the collec‐
tion store for the target collection. See Figure 4-8 .
Whilst eXist does indeed store the contents of your binary docu‐
ments as a series of files on disk, you should not manually change
the files in the $EXIST_HOME/webapp/WEB-INF/data/fs folder, as
eXist will be unaware of the changes that you have made. Any
changes to this folder could cause the database to lose integrity for
binary resources and could lead to stability issues.
While the storage of binary documents into eXist is relatively sim‐
ple (i.e., the content is maintained in files on disk and additional
metadata is maintained in eXist's collection store), you can go fur‐
ther by making use of eXist's binary content extraction facilities
(see contentextraction ) to enable indexing and search of binary
documents.
Efficient XML Processing Architecture
There are several crosscutting concerns of eXist's architecture that focus on efficient
XML processing and storage; we will take a look at a couple of the more significant
ones next. These topics are certainly advanced and may be skipped if you are not
interested in eXist's internals.
There are three levels of granularity that eXist is concerned with:
Collection
An arbitrary grouping of XML and binary documents
Document
Either an XML document or a binary document
Node
The nodes within XML documents (i.e., elements, attributes, text, etc.)
Search WWH ::




Custom Search