Skip to content
  1. Jul 18, 2016
  2. Jul 14, 2016
    • gmantele's avatar
      [TAP] Fix an artefact of 19026c1b. · 6ba9bffb
      gmantele authored
      TAPTable.copy(...) and TAPColumn.copy(...) use directly the attribute dbName
      instead using getDBName() ; indeed getDBName() <> dbName.
      Because of this bug, queries with aliased tables did not work anymore.
      6ba9bffb
    • gmantele's avatar
      [TAP] Add a TAP 1.1 feature: table_index and column_index in TAP_SCHEMA. · 6fc7f8fd
      gmantele authored
      These two columns let recommend an order, respectively, for tables in their
      schema, and columns in their table.
      In addition of these new columns, "arraysize" has been also added.
      All these new columns are already supported when creating a TAP_SCHEMA from
      an XML file.
      6fc7f8fd
  3. Jul 13, 2016
  4. Jul 12, 2016
  5. Jul 01, 2016
  6. Jun 16, 2016
  7. Jun 13, 2016
  8. Jun 08, 2016
  9. May 25, 2016
    • gmantele's avatar
      [ADQL] Fix recursive replacement using SimpleReplaceHandler. · ad2acca3
      gmantele authored
      Before correction, if an ADQlObject (e.g. a function or a sub-query) contains
      another ADQLObject and that both (i.e. parent and child) are matching in a
      SimpleReplaceHandler and are asked to be replaced, only the parent
      seemed to have been replaced. However, the child has been replaced, but
      in the former instance of the parent ; and so its replacement is not
      visible in the final query.
      
      For instance:
      if all mathematical functions must be replaced by a dumb UDF named 'foo' in
      the ADQL query:
              "SELECT sqrt(abs(81)) FROM myTable"
      ,the result should be:
              "SELECT foo(foo(81)) FROM myTable"
      ,but before this correction it was:
              "SELECT foo(abs(81)) FROM myTable".
      ad2acca3
  10. Apr 20, 2016
  11. Apr 19, 2016
    • gmantele's avatar
      [TAP] Finish fixing the transaction management bug. · 5ac8f1fb
      gmantele authored
      See the commit bd621842,
      for the first part of the fix (which actually did not really
      fixed the problem: connections "idle in transaction" were
      still in the database ; the connection being inside an opened transaction,
      it generates lock issues in the database in addition of probably taking
      some memory resources).
      5ac8f1fb
  12. Apr 12, 2016
    • gmantele's avatar
      [TAP] New fix for the transaction management. · bd621842
      gmantele authored
      The transaction and Statement were closed too early before.
        - Fetching the row was not possible once the first bunch of fetched
      rows was over.
        - The problem of "statement is aborted" preventing the re-use of
      a same DB connection was apparently still there, but occurred less often.
      
        Now, any transaction potentially started in a DB connection is always
      closed after one of the public functions of JDBCConnection is called ;
      except executeQuery(ADQLQuery) whose the call MUST be wrapped inside a
      try...catch block in which DBConnection.cancel(true) MUST be called
      in case of error (in order to effectively end any started transaction).
      bd621842
  13. Mar 17, 2016
  14. Mar 04, 2016
    • gmantele's avatar
      [ADQL] Set a type to a query's resulting column when it is not originally a column. · 0003e343
      gmantele authored
      This is easily possible for concatenations, string constants and User Defined
      Functions having a FunctionDef. A new special datatype was needed for
      numeric functions and operations: UNKNOWN_NUMERIC. This special type
      can not be set with FunctionDef.parse(...) and it behaves exactly like the type
      UNKNOWN, except that DBType.isNumeric() returns true (as .isUnknown()).
      Thus, while writing the metadata of a result in TAP, nothing changes:
      an UNKNOWN_NUMERIC type will be processed similarly as an UNKNOWN type:
      to use the type returned from the database ResultSet or to set VARCHAR.
      (no modification of TAP was needed for that)
      0003e343
    • gmantele's avatar
      [ADQL] Fix identification of UDFs using a list of function definitions. · 475fcb65
      gmantele authored
      Functions whose some parameters are another function were not correctly
      identified: since the inner functions were not yet identified, their type
      was UNKNOWN and so it makes the identification of the parent function
      much easier since an UNKNOWN parameter is not checked. But, it was a
      problem if the parameter occurs to be finally of the wrong type.
      475fcb65
    • gmantele's avatar
      [ADQL] Return a not NULL name for a SelectItem containing a Concatenation · 09e81ed7
      gmantele authored
      (indeed, a Concatenation object has no name).
      09e81ed7
  15. Feb 10, 2016
  16. Feb 08, 2016
  17. Jan 29, 2016
  18. Jan 13, 2016
  19. Jan 12, 2016
  20. Dec 11, 2015
  21. Dec 04, 2015
  22. Dec 01, 2015
  23. Nov 19, 2015
    • gmantele's avatar
      [TAP] New feature: Examples endpoint. · f4f05986
      gmantele authored
      Can be enabled just by providing a file URI in the TAP configuration file using
      the property "examples". It is also possible to add manually a TAP resource
      whose the returned name must be "examples" like the new TAP resource is doing:
      tap.resource.Examples. This latter take a file URI as the TAP configuration
      file does. The referenced file must respect the DALI 1.0 or TAP Notes 1.0
      syntax. No check of the file is performed by the library ; it is up to the
      author of the referenced file (a XHTML/RDFa file) to write a correct "examples"
      endpoint content. Check out the examples provided on the GitHub repository in
      the directory examples/tap/examples_endpoint.
      f4f05986
  24. Nov 13, 2015
    • gmantele's avatar
      [TAP & UWS] 2 MAJOR BUGS FIXED (these bugs were affecting performances). · d9041712
      gmantele authored
      1) [TAP & UWS] ]MAJOR BUG FIX: The abortion of an SQL query is now correctly
      implemented. Before this fix, 2 mistakes prevented this clean abortion:
        a/ The thread was not cancelled because the SQL query execution was
      blocking the thread. Then the thread could not treat the interruption though
      it was flagged as interrupted.
        b/ The function UWSJob.isStopped() considered the job as stopped because
      the interrupted flag was set, even though the thread was still processing
      (and the database too). Because of that it returned true and the job phase
      was ABORTED though the thread was still running.
        NOW:
        a/ TAPJob calls the function Statement.cancel() (if supported) in order
      to cancel the SQL query execution properly inside the database.
        b/ The function UWSJob.isStopped() does not test any more the interrupted flag
      and returns true only if the thread is really stopped.
        IN BRIEF: It is now sure that a job in the phase ABORTED is really stopped
      (that's to say: thread stopped AND DB query execution stopped).
      
      2) [TAP] BUG FIX: When the writing of a result is abnormaly interrupted for any
      reason, the file which was being written is deleted.
      d9041712
  25. Oct 22, 2015
  26. Oct 16, 2015
  27. Sep 30, 2015
  28. Sep 10, 2015