1. 08 Aug, 2022 1 commit
  2. 06 Aug, 2022 1 commit
  3. 02 Aug, 2022 1 commit
  4. 31 Jul, 2022 1 commit
  5. 29 Jul, 2022 1 commit
  6. 28 Jul, 2022 1 commit
    • Carlos Garnacho's avatar
      libtracker-sparql/core: Use boolean getter for ASK query · d5550e7e
      Carlos Garnacho authored
      During ontology updates, we ask our own database about changes in
      certain properties for our incompatible change checks. Specifically
      for nrl:InverseFunctionalProperty checks, we are using an ASK query
      to check for properties being such prior to the ontology updates.
      However, we are using the internal get_int() cursor getter, whereas
      the result of an ASK query is either a boolean, or "true"/"false"
      strings, since it's internally provided as the latter, get_int()
      falls short and always returns 0.
      Deal with this as a boolean using the high-level TrackerSparqlCursor
      API instead. This fixes the misdetection of changes about
      nrl:InverseFunctionalProperty properties during ontology updates,
      when possibly none was done.
      While at it, shuffle a bit the code to propagate errors, and free
      the cursor on all situations.
  7. 27 Jul, 2022 1 commit
  8. 26 Jul, 2022 1 commit
  9. 24 Jul, 2022 1 commit
  10. 23 Jul, 2022 4 commits
  11. 22 Jul, 2022 1 commit
  12. 20 Jul, 2022 1 commit
  13. 19 Jul, 2022 4 commits
  14. 18 Jul, 2022 1 commit
  15. 17 Jul, 2022 5 commits
    • Carlos Garnacho's avatar
      build: Cleanse of Vala dependencies · aea373bc
      Carlos Garnacho authored
      Drop all the places left where we do specify things for Vala,
      and rename the targets that had that name because of vala code
    • Carlos Garnacho's avatar
      libtracker-sparql: Reimplement all bus connection objects · 4098bbda
      Carlos Garnacho authored
      Historically the set of objects that provide the bus implementation
      were written in Vala, this commit ends with that and rewrites all of
      these objects in C. This is mostly a 1:1 port with one exception,
      cursors are now based on TrackerDeserializer and input streams, they
      were given a memory buffer previously.
      The use of Vala here had a few indirect effects:
      - Vala code could not be introspected by our gcovr infrastructure for
        code coverage. This made this central piece of our library invisible
        to coverage stats entirely.
      - Since our library code and vala contend for the use of visibility
        attributes for public functions, we ended up with a few symbols from
        this Vala code that was never intended to be public API.
      - The async code generated by Vala triggers reports about unreachable
        code in Coverity. This has proven very imbued in Vala and hard to
        fix without breaking something else there.
      Moving away from Vala fixes all 3. For the sake of maintainability,
      this is seen as a net improvement, despite the more verbose code and
      the async operation daisy chaning at places. Now all untested code,
      leaked symbols and dead code will be a responsibility of our own.
    • Carlos Garnacho's avatar
      libtracker-sparql: Reply earlier to D-Bus query messages in endpoints · 42541130
      Carlos Garnacho authored
      Currently, the endpoint waits to write the full cursor contents before
      replying to a Query D-Bus request. This relies on the caller side
      simultaneously issuing the D-Bus request and reading all data from
      the cursor, so that on the endpoint side writing the cursor does not
      end up blocking when the buffer grew too large.
      This relies on the bus TrackerSparqlConnection side doing exactly
      that, and splicing all cursor contents in a memory buffer, This is
      however not friendly to an approach using input streams, since the
      TrackerSparqlConnection side would read pipe contents incrementally
      while iterating the cursor, but it didn't get it yet since the
      endpoint will end up clogging the pipe and the Query request will
      not be replied.
      In order to fix this, reply the D-Bus request before writing the
      cursor contents, so that the other end can get ahead with creating
      a TrackerSparqlCursor that will stream the contents during iteration.
      As a result the errors happening during writes are not forwarded to
      the other end anymore, but since they would mostly consist of write
      errors, it sounds likely the other end had some involvement in that
      (e.g. dying or prematurely closing the cursor).
    • Carlos Garnacho's avatar
      utils: Drop tracker-resdump noinst util · d3fec06c
      Carlos Garnacho authored
      This small utility prints Turtle for resources in the miner fs
      database. It's from the olden days that introspection through
      SPARQL queries was limited, we didn't have RDF production
      capabilities, and there was an unique store.
      We currently have this feature built in, and available through
      "tracker3 export", there is no need for this ad-hoc util executable
    • Carlos Garnacho's avatar
      libtracker-sparql: Declare direct connection constructors in C code · dad6b5f0
      Carlos Garnacho authored
      We currently have a series of vapi files, just so that the
      TrackerSparqlConnection constructors are defined in tracker-backend.vala.
      Shuffle this so that we declare the direct connection right at
      tracker-connection.c, and avoid/drop all those vapi files.
  16. 15 Jul, 2022 1 commit
  17. 14 Jul, 2022 3 commits
  18. 13 Jul, 2022 6 commits
  19. 12 Jul, 2022 1 commit
  20. 11 Jul, 2022 4 commits