Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would think that an <a href="http://www.vincehuston.org/dp/observer.html" rel="nofollow noreferrer">Observer Pattern</a> might be adapted.</p> <p>The idea would be that each <code>Node</code> maintains a precomputed list and is simply notified by its parent of any update so that it can recompute this list.</p> <p>This can be done in 2 different ways:</p> <ol> <li>notify that a change occurred, but don't recompute anything</li> <li>recompute at each update</li> </ol> <p>I would advise going with <code>1</code> if possible, since it does not involve recomputing the whole world when root is updated, and only recomputing when needed (lazy eval in fact) but you might prefer the second option if you update rarely but need blazing fast retrieval (there are more concurrency issues though).</p> <p>Let's illustrate Solution 1:</p> <pre><code>Root ___ Node1 ___ Node1A \ \__ Node1B \_ Node2 ___ Node2A \__ Node2B </code></pre> <p>Now, to begin with, none of them has precomputed anything (there are all in a dirty state), if I ask for <code>Node2A</code> rules:</p> <ul> <li><code>Node2A</code> realizes it is dirty: it queries <code>Node2</code> rules</li> <li><code>Node2</code> realizes it is dirty: it queries <code>Root</code></li> <li><code>Root</code> does not have any parent, so it cannot be dirty, it sends its rules to <code>Node2</code></li> <li><code>Node2</code> caches the answer from <code>Root</code>, merges its rules with those received from <code>Root</code> and cleans the dirty bit, it sends the result of the merge (cached now) to <code>Node2A</code></li> <li><code>Node2A</code> caches, merges, cleans the dirty bit and returns the result</li> </ul> <p>If I subsequently asks for <code>Node2B</code> rules:</p> <ul> <li><code>Node2B</code> is dirty, it queries <code>Node2</code></li> <li><code>Node2</code> is clean, it replies</li> <li><code>Node2B</code> caches, merges, cleans the dirty bit and returns the result</li> </ul> <p>Note that <code>Node2</code> did not recomputed anything.</p> <p>In the update case:</p> <ul> <li>I update <code>Node1</code>: I use the <code>Root</code> cached rules to recompute the new rules and send a beat to <code>Node1A</code> and <code>Node1B</code> to notify them their cache is outdated</li> <li><code>Node1A</code> and <code>Node1B</code> set their dirty bit, they would also have propagated this notification had they had children</li> </ul> <p>Note that because I cached <code>Root</code> rules I don't have to query the <code>Root</code> object, if it's a simple enough operation, you might prefer not to cache them at all: if you're not playing distributed here, and querying <code>Root</code> only involves a memory round-trip you might prefer not to duplicate it in order to save up some memory and book-keeping.</p> <p>Hopes it gets you going.</p>
    singulars
    1. This table or related slice is empty.
    1. POStrategies for quickly traversing an ACL
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMatthieu M.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POStrategies for quickly traversing an ACL
      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. VTUpMod
    1. COVery helpful response, I suppose that you are implicitly saying: precompute all (in a more or less complex strategy).
      singulars
      1. PO
      1. USMarc Climent
    2. CONot at all, it's wasteful. I mean to compute lazily (compute on need, and cache the result) and to use the observer pattern to know when the cached result is deprecated.
      singulars
      1. PO
      1. USMatthieu M.
 

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