Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It's a limitation of the zipper data structure. Zippers are designed for efficiently navigating trees of various sorts, with support for moving up/down/left/right in the tree hierarchy, with in-place edits in near-constant time.</p> <p>From any position in the tree, the zipper needs to be able to re-construct the original tree (with edits applied). To do that, it keeps track of the current node, the parent node, and all siblings to the left and right of the current node in the tree, making heavy use of persistent data structures.</p> <p>The filter functions that you're using start at the left-most child of a node and work their way one-by-one to the right, testing predicates along the way. The zipper for the left-most child starts out with an empty vector for its left-hand siblings (note the <code>:l []</code> part in the source for <a href="https://github.com/clojure/clojure/blob/clojure-1.5.1/src/clj/clojure/zip.clj#L109" rel="nofollow noreferrer">zip/down</a>). Each time you move right, it will add the last node visited to the vector of left-hand siblings (<code>:l (conj l node)</code> in <a href="https://github.com/clojure/clojure/blob/clojure-1.5.1/src/clj/clojure/zip.clj#L149" rel="nofollow noreferrer">zip/right</a>). By the time you arrive at the right-most child, you've built up an in-memory vector of all the nodes in that level in the tree, which, for a wide tree like yours, could cause an OOM error.</p> <p>As a workaround, if you know that the top-level element is just a container for a list of <code>&lt;page&gt;</code> elements, I'd suggest using the zipper to navigate within the page elements and just use <code>map</code> to process the pages:</p> <pre><code>(defn titles "Extract titles from +filename+" [filename] (let [xml (xml/parse filename)] (map #(xml-&gt; (zip/xml-zip %) :title text) (:content xml)))) </code></pre> <p><em>So, basically, we're avoiding using the zip abstraction for the top level of the overall xml input, and thusly avoid its holding the entire xml in memory</em>. This implies that for even huger xml, where each first-level child is huge, we may have to skip using the zipper once again in the second level of the XML structure, and so on...</p>
    singulars
    1. This table or related slice is empty.
    1. POOutOfMemoryError when parsing XML in Clojure with data.zip
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USmatanster
    1. USAlex
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOutOfMemoryError when parsing XML in Clojure with data.zip
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload