git.oblomov.eu Git - ikiwiki/blob - doc/bugs/depends_simple_mixup.mdwn

   1 The [[bugs]] page, at least before I commit this, has a bug at the top that
   2 has been modified to link to done, and ikiwiki's dependency calculations
   3 failed to notice and update the bugs page. Looking at the indexdb, I saw
   4 that the page was not included in the `depends_simple` of the bugs page.
   5
   6 I was able to replicate the problem locally by starting off with the page
   7 marked done (when it did appear in the bugs page `depends_simple`
   8 (appropriatly as a link dependency, since a change to the page removing the
   9 link would make it match)), then removing the done link.
  10
  11 At that point, it vanished from `depends_simple`. Presumably because
  12 the main (pagespec) depends for the bugs page now matched it, as a content
  13 dependency. But, it seems to me it should still be listed in
  14 `depends_simple` here. This, I think, is the cause of the bug.
  15
  16 Then re-add the done link, and the dependency calc code breaks down,
  17 not noticing that bugs dependeded on the page and needs to be updated.
  18
  19 Ok.. Turns out this was not a problem with the actual influences
  20 calculation or dependency calculation code. Whew! `match_link`
  21 just didn't set the influence correctly when failing. fixed
  22
  23 --[[Joey]]
  24
  25 ---
  26
  27 Update: Reopening this because the fix for it rather sucks.
  28
  29 I made `match_link` return on failure an influence of
  30 type DEPEND_LINKS. So, a tag page that inlines `tagged(foo)`
  31 gets a `depends_simple` built up that contains link dependencies for
  32 *every* page in the wiki. A very bloaty way to represent the dependency!
  33
  34 Per [[todo/dependency_types]], `link(done)` only needs to list in
  35 `depends_simple` the pages that currently match. If a page is modified
  36 to add the link, the regular dependency calculation code notices that
  37 a new page matches. If a page that had the link is modified to remove it,
  38 the `depends_simple` lets ikiwiki remember that the now non-matching page
  39 matched before.
  40
  41 Where that fell down was `!link(done)`. A page matching that was not added
  42 to `depends_simple`, because the `link(done)` did not match it. If the page
  43 is modified to add the link, the regular dependency calculation code
  44 didn't notice, since the pagespec no longer matched.
  45
  46 In this case, `depends_simple` needs to contain all pages
  47 that do *not* match `link(done)`, but before my change, it contained
  48 all pages that *do* match. After my change, it contained all pages.
  49
  50 ----
  51
  52 So, seems what is needed is a way for influence info to be manipulated by
  53 the boolean operations that are applied. One way would be to have two
  54 sets of influences be returned, one for successful matches, and one for
  55 failed matches. Normally, these would be the same. For successful
  56 `match_link`, the successful influence would be the page.
  57 For failed `match_link`, the failed influence would be the page.
  58
  59 Then, when NOTting a `*Reason`, swap the two sets of influences.
  60 When ANDing/ORing, combine the individual sets. Querying the object for
  61 influences should return only the successful influences.
  62
  63 ----
  64
  65 Would it be possible to avoid the complication of maintianing two sets of
  66 influence info?
  67
  68 Well, notice that the influence of `pagespec_match($page, "link(done)")`
  69 is $page. Iff the match succeeds.
  70
  71 Also, the influence of `pagespec_match($page, "!link(done)")` is
  72 $page. Iff the (overall) match succeeds.
  73
  74 Does that hold for all cases? If so, the code that populates
  75 `depends_simple` could just test if the pagespec was successful, and
  76 if not, avoid adding $page influences, while still adding any other,
  77 non-$page influences.
  78
  79 ----
  80
  81 Hmm, commit f2b3d1341447cbf29189ab490daae418fbe5d02d seems
  82 thuroughly wrong. So, what about influence info for other matches
  83 like `!author(foo)` etc? Currently, none is returned, but it should
  84 be a content influence. (Backlink influence data seems ok.)
  85
  86 ----
  87
  88 [[done]] again!