Skip to content
Snippets Groups Projects
  1. Feb 22, 2017
  2. Feb 20, 2017
  3. Feb 01, 2017
  4. Sep 20, 2016
    • gmantele's avatar
      [ADQL] Fix the tree generated by the parsing of NATURAL JOINs. · 7ca49f81
      gmantele authored
      The "normal" JOIN:
          A JOIN B ON A.id = B.id JOIN C ON B.id = C.id
      is correctly interpreted as:
          ( (A JOIN B ON A.id = B.id) JOIN C ON B.id = C.id )
      But with a NATURAL JOIN, the tree is mirrored:
          A NATURAL JOIN B NATURAL JOIN C
      gives:
      	( A NATURAL JOIN (B NATURAL JOIN C) )
      instead of:
          ( (A NATURAL JOIN B) NATURAL JOIN C )
      This is not a problem when the SQL translation is identical to the ADQL
      expression, but for some DBMS a conversion into a INNER JOIN ON is necessary
      and in this case we got the following SQL:
          A JOIN B JOIN C ON A.id = B.id ON B.id = C.id
      Which seems to work, but is syntactically strange.
      
      This commit should fix the generated tree. A "normal" JOIN and a NATURAL JOIN
      should now have the same form. A JUnit test has been added into TestADQLParser
      to check that: testJoinTree().
      7ca49f81
  5. Sep 14, 2016
  6. Jul 13, 2016
  7. Jun 13, 2016
  8. 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
  9. Apr 20, 2016
  10. Mar 17, 2016
    • gmantele's avatar
      [ADQL] Add an ADQL translator for MS SQL Server. This particular translator · a2fb29ad
      gmantele authored
      deals with NATURAL JOINs and JOINs using the keyword USING so that being
      supported by SQL Server. Basically, they are translated as a list of ON
      conditions.
      Warning: This translator is just guaranteed to solve the NATURAL and USING
      issue. Support for datatypes conversion and case sensitivity has to be
      reviewed. Besides no geometrical function is translated for SQL Server.
      a2fb29ad
  11. 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
  12. Feb 08, 2016
  13. Dec 11, 2015
  14. Dec 01, 2015
  15. Oct 22, 2015
  16. Sep 30, 2015
  17. Sep 01, 2015
    • gmantele's avatar
      [ADQL,TAP] Fix bug (reported by G. Landais) in the understanding of UNKNOWN · 271e03cc
      gmantele authored
      types. The notion of "unknown type" is different in function of the target
      object:
        - a DBType and a FunctionDef have an unknown type if their function
          isUnknown() returns true. In such case, the other functions such as
      	isNumeric/String/Geometry() will return false.
        - an ADQLOperand (e.g. ADQLColumn) does NOT have a isUnknown() function.
          But if the type of the operand is unknown, its functions isNumeric(),
      	isString() and isGeometry() must ALL return true. Otherwise, just one of
      	these functions can return true.
      271e03cc
  18. Aug 27, 2015
    • gmantele's avatar
      [ADQL] Fix a Big Bug reported by M.Taylor and M.Demleitner: in ORDER BY, GROUP... · 13a2dc54
      gmantele authored
      [ADQL] Fix a Big Bug reported by M.Taylor and M.Demleitner: in ORDER BY, GROUP BY and USING only regular and delimited identifiers are accepted, not qualified column names.
      For instance: "SELECT table.column_name FROM table ORDER BY table.column_name" is wrong. We should instead write:
      "SELECT table.column_name FROM table ORDER BY column_name".
      "SELECT table.column_name AS mycol FROM table ORDER BY mycol" is also correct.
      Of course, for ORDER BY and GROUP BY, it is still possible to reference a column using its index in the SELECT clause.
      For instance: "SELECT table.column_name FROM table ORDER BY 1".
      13a2dc54
  19. Aug 25, 2015
    • gmantele's avatar
      [ADQL] Fix a bug reported by M. Taylor about qualified table name: · 84ede4bf
      gmantele authored
      when in a table definition (extension of DBTable) no schema is
      specified, it was possible to prefix the table name by a fake
      schema name ; it was checked at all:
      e.g. "SELECT * FROM no_schema.foo".
      This is no longer possible: if no schema is specified, no schema
      must be used in an ADQL query. But if one is specified, the schema
      prefix is optional.
      84ede4bf
  20. Aug 03, 2015
    • gmantele's avatar
      [ADQL,TAP] Fix 2 bugs notified by M.Taylor: · b49f8160
      gmantele authored
      1/ Bad parsing of UDF's parameter type or return type. Database types whose the
      name has a space (e.g. 'double precision') were not accepted. These type names
      should be accepted according to TAPRegExt.
      2/ An error message thrown by the DBChecker has been modified for the cases
      the type of a parameter is unknown. Before the returned type was NUMERIC. Now,
      it will be 'param' followed by the parameter index (e.g. 'param1').
      b49f8160
  21. Jul 20, 2015
  22. Jun 16, 2015
  23. Jun 09, 2015
  24. Jun 08, 2015
  25. Apr 22, 2015
  26. Apr 13, 2015
  27. Mar 26, 2015
  28. Mar 11, 2015
  29. Mar 04, 2015
  30. Feb 27, 2015
  31. Feb 20, 2015
  32. Feb 19, 2015
  33. Feb 18, 2015
Loading