1. 04 Jul, 2020 9 commits
    • Carlos Garnacho's avatar
      libtracker-miner: Drop unused enum · 51f933ef
      Carlos Garnacho authored
      This went unused when we stopped having per-event queues.
      51f933ef
    • Carlos Garnacho's avatar
      libtracker-miner: Drop filter_event vfunc · eca20b67
      Carlos Garnacho authored
      This went unused with the removal of writeback miner hooks.
      eca20b67
    • Carlos Garnacho's avatar
      tracker-miner-fs: Move files into the tracker:FileSystem graph · 42b506b5
      Carlos Garnacho authored
      The ::move-file event didn't get properly updated to the usage of the
      tracker:FileSystem graph, writing the new files in the default graph.
      Make it use the filesystem graph as it should.
      42b506b5
    • Carlos Garnacho's avatar
      libtracker-miner: Perform URN queries in the tracker:FileSystem graph · 97ce1959
      Carlos Garnacho authored
      The upper layers nowadays just poke URNs for folders, whose information
      element is guaranteed to be in the tracker:FileSystem graph. This results
      in a simpler and faster query.
      97ce1959
    • Carlos Garnacho's avatar
      libtracker-miner: Do not force URN query from the upper layers · e81f23b0
      Carlos Garnacho authored
      With the pre-caching now done correctly for all files we care about
      (folders basically), we can avoid forcing queries here if the URN is
      not found.
      
      Results in less queries on first-time index, since we are querying
      anyway for URNs that we know are not there.
      
      It is worth noting that queries will be implicitly forced here for
      folders with an invalidated URN, this only happens if the queried
      file was freshly inserted in the DB.
      e81f23b0
    • Carlos Garnacho's avatar
      libtracker-miner: Rework pre-caching of information element URNs · 81d0dfbd
      Carlos Garnacho authored
      The use of information element URNs is pretty much reserved now to
      folders. We can avoid trying to cache it for every file, we also
      need to do it preemptively on less situations.
      81d0dfbd
    • Carlos Garnacho's avatar
      libtracker-miner: Simplify URN getters · fb1a99cf
      Carlos Garnacho authored
      We have one getter for the URN as contained in the update task,
      and another that pokes the filesystem, and resorts to querying
      otherwise.
      
      As we basically want to deal with folders here, and those get
      conveniently cached in the TrackerFileSystem, rely on the latter
      for all places where we need a folder URN.
      fb1a99cf
    • Carlos Garnacho's avatar
      libtracker-miner: Add notifier query to check for file existence · 91e6b2f2
      Carlos Garnacho authored
      When handling a move event, the miner checks that the source file existed
      previously by checking the information element URN. Add an extra file
      notifier query that checks the nfo:FileDataObject existence in the
      tracker:FileSystem graph instead.
      
      This avoids having to poke every other graph in order to get this URN.
      91e6b2f2
    • Carlos Garnacho's avatar
      tracker-miner-fs: Drop special case for update vs create · 9c142796
      Carlos Garnacho authored
      We query the URN here as a mean to check that a file was already
      added, and do things that should essentially turn into no-ops in
      the case of a create event (as the resource would exist previously).
      
      Drop the URN check here, makes create/update events handled all the
      same, and avoids having to query information elements for things
      that are not folders.
      
      Besides, this fixes a funky side effect of our event coalescing wrt
      writeback: We write the file in a temporary hidden file and then
      move onto the original location. Sometimes we get to coalesce
      CREATE(A)+MOVE(A,B) as CREATE(B) right away, without checking that
      B exists. This skips the the extractorHash property deletion, so
      tracker-extract doesn't get to re-extract the file. If we handle
      creates and updates the same way, this is moot.
      9c142796
  2. 03 Jul, 2020 6 commits
  3. 29 Jun, 2020 2 commits
  4. 28 Jun, 2020 2 commits
  5. 27 Jun, 2020 6 commits
  6. 25 Jun, 2020 2 commits
  7. 24 Jun, 2020 1 commit
  8. 23 Jun, 2020 1 commit
  9. 22 Jun, 2020 4 commits
  10. 21 Jun, 2020 7 commits