Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-8237

Clarify policy on the use of the qserv_ vs. scisql_ functions for spherical geometry queries

    XMLWordPrintable

    Details

    • Type: Story
    • Status: In Progress
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: Qserv
    • Labels:
    • Story Points:
      0.25
    • Sprint:
      DB_F20_09, DB_S21_12, DB_F21_06, DB_S22_12, DB_F22_6, DB_S23_6
    • Team:
      Data Access and Database
    • Urgent?:
      No

      Description

      Please clarify whether the operational DAX+Qserv system should be queried using the qserv_* family of functions (UDFs) or the corresponding scisql_* functions.

      Example: qserv_areaspec_circle versus scisql_s2PtInCircle.

      From documentation I can see, the scisql_* functions may be a (substantial) superset of the qserv_* functions.

      I understand that the answer to this question may be different for the 2016-17 PDAC versus the planned final system.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            Has this ticket become irrelevant now that we are using ADQL?

            Show
            tjenness Tim Jenness added a comment - Has this ticket become irrelevant now that we are using ADQL?
            Hide
            fritzm Fritz Mueller added a comment -

            I believe so (yes, now irrelevant).

            TAP notwithstanding, Qserv itself also now automatically infers the most common area restrictions directly from `scisql_s2PtIn...`.

            Gregory Dubois-Felsmann: please set status to "Invalid" if you feel the issue is satisfactorily resolved, or clarify required further action here if not?

            Kian-Tat Lim: Was the status update to "In Review" on 09/Nov/16 intentional?  I do not see any linked ticket.  Is/was there material requiring review?

            Show
            fritzm Fritz Mueller added a comment - I believe so (yes, now irrelevant). TAP notwithstanding, Qserv itself also now automatically infers the most common area restrictions directly from `scisql_s2PtIn...`. Gregory Dubois-Felsmann : please set status to "Invalid" if you feel the issue is satisfactorily resolved, or clarify required further action here if not? Kian-Tat Lim : Was the status update to "In Review" on 09/Nov/16 intentional?  I do not see any linked ticket.  Is/was there material requiring review?
            Hide
            ktl Kian-Tat Lim added a comment -

            As I said at the time, the status was updated to "In Review" because I was asserting that existing documentation already clarified this policy and wanted a check on that.

            Show
            ktl Kian-Tat Lim added a comment - As I said at the time, the status was updated to "In Review" because I was asserting that existing documentation already clarified this policy and wanted a check on that.
            Hide
            fritzm Fritz Mueller added a comment -

            Thanks, Kian-Tat Lim (sorry I missed your original comment above the fold).  I'll attach this to our current F20 doc epic, and close it when we've updated UserManual.md wrt. auto-inferred spatial constraints.

            Show
            fritzm Fritz Mueller added a comment - Thanks, Kian-Tat Lim (sorry I missed your original comment above the fold).  I'll attach this to our current F20 doc epic, and close it when we've updated UserManual.md wrt. auto-inferred spatial constraints.
            Hide
            tjenness Tim Jenness added a comment -

            It seems like this ticket is still relevant in that we are allowing scisql calls directly into the ADQL.

            We need to make a decision about this, maybe on a new ticket, since we have to be intentional about extensions to ADQL given:

            • We are promising to support those extensions for a long time since people want their queries to work.
            • We need to minimize these extensions (do not use scisql for sky area when ADQL works fine)
            • We need to whitelist specific extensions.
            • We should consider renaming them so they are not locking us into scisql if at some point we change from mariadb.
            Show
            tjenness Tim Jenness added a comment - It seems like this ticket is still relevant in that we are allowing scisql calls directly into the ADQL. We need to make a decision about this, maybe on a new ticket, since we have to be intentional about extensions to ADQL given: We are promising to support those extensions for a long time since people want their queries to work. We need to minimize these extensions (do not use scisql for sky area when ADQL works fine) We need to whitelist specific extensions. We should consider renaming them so they are not locking us into scisql if at some point we change from mariadb.

              People

              Assignee:
              fritzm Fritz Mueller
              Reporter:
              gpdf Gregory Dubois-Felsmann
              Reviewers:
              Fritz Mueller
              Watchers:
              Brian Van Klaveren, Christine Banek, Fritz Mueller, Gregory Dubois-Felsmann, Kian-Tat Lim, Serge Monkewitz, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:

                  Jenkins

                  No builds found.