Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • tracker tracker
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 79
    • Issues 79
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 11
    • Merge requests 11
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • trackertracker
  • Issues
  • #144
Closed
Open
Issue created Sep 22, 2019 by Carlos Garnacho@carlosgMaintainer

TrackerSparqlStatement should rebuild SQL on graph changes

Starting with the sparql1.1 support, we now generate SQL that is slightly dependent on the currently attached databases (which we use for graph support). What happens then is that if graphs are created or dropped, older SQL generated before the change may be rendered less optimal, or result in query errors.

This is usually not a problem, except in TrackerSparqlStatement, as its business is precisely caching the SPARQL->SQL translation.

TrackerDataManager internally keeps the accounting of such graph changes, it should be possible to make built statements check themselves before execution, and transparently trigger the re-generation of the SQL if necessary.

Assignee
Assign to
Time tracking