Currently we enforce in DataIntegrity that ints are ints and strings are strings, but we don't check lengths (like varchar(N) and int vs. bigint). We do parse this information so this shouldn't be too hard.

Like this:

SET ...
FROM table1 t1 JOIN table2 t2 ON t1.id = t2.t1_id WHERE ...

Found and fixed this bug in the PHP version:

This query

SELECT * FROM (SELECT * FROM `foo` UNION ALL SELECT * FROM `bar`) AS `baz`

is treated as

SELECT * FROM (SELECT * FROM `foo`) AS `baz`

Here's the commit with the fix in the PHP version, you should be able to port it relatively straightforwardly if you run into the same issue.

Issue template for hack-sql-fake

Please select the options that apply

• Feature request
• Question
• Suggestion
• Typechecker errors
• Incorrect result
• Cripplingly bad performance
• Crash

Follow the template for your checked checkbox and then delete the templates.

Feature request

I would like to have an implementation of `AsyncMysqlQueryErrorResult` and `SQLFakeAsyncMysqlException` that behaves similarly to `AsyncMysqlException`. 
This is an SQL/AsyncMysql feature.

`AsyncMysqlQueryErrorResult` should allow for setting the error code and error message of the result in its constructor.
`SQLFakeAsyncMysqlException` should allow for setting the `AsyncMysqlErrorResult` in its constructor.

Should only be enabled in 5.7 mode

https://dev.mysql.com/doc/refman/5.7/en/json.html

The column type is just treated as a string so that part's easy, but the functions are the interesting parts.

It is awesome tool, but may be exists something similar for postgresql?

Issue template for hack-sql-fake

• [ X ] Question

Question

QQ: I took a Keyset\diff of Operator::getValues() and SQLParser::OPERATORS. There are some operators that the parser does not know about that do have an implementation in the rest of the code. Think of RLIKE. Others are only used in this block.

      case Operator::ANY: // parser does NOT KNOW about this functionality
      case Operator::SOME: // parser does NOT KNOW about this functionality
      //[[fallthrough]] <- note to humans, not to the typechecker, therefore different syntax.
      default:
        throw new SQLFakeRuntimeException("Operator {$this->operator} not implemented in SQLFake");

For maintainability I would like to end up with declaring the enum only once. This will require some filtering on the SQLParser constant. This will nolonger allow it to be a constant. Could something like this be done in the future?

class SQLParser{
  visibility static function getParsableOperators(): keyset<Operator>{
    return Keyset\filter(Operator::getValues(), $op ==> self::isImplemented($op));
  }
}

Parse them, store them in schema, and actually check them

This line makes all the return values strings, even the NULL values. https://github.com/slackhq/hack-sql-fake/blob/master/src/AsyncMysql/AsyncMysqlQueryResult.php#L42
According to the documentation the return type should be Vector<Map<string, string>>, but that seems off. The HHI agrees with that too. However the documentation describes string|null.
https://docs.hhvm.com/hack/reference/class/AsyncMysqlQueryResult/mapRows/#examples

Are we sure the return type isn't secretly Map<string, ?string>?

Issue template for hack-sql-fake

• [ X ] Question

Question

This line https://github.com/slackhq/hack-sql-fake/blob/master/src/Expressions/FunctionExpression.php#L21 takes a $this->type TokenType::enum and casts it to a string. It then assigns it to a property called $this->operator string. I presume that this property must have the type ?Operator::enum (new in #21). It seems very weird that these values are valid members of Operator::enum.

• Should I add the to these values Operator::enum too? If no, what should I do with this assignment? HH_FIXME will be required.
• If not, adding them to the Operator::enum will make the code less maintainable, since Hack does not support this.

enum ONE: int { ONE = 1; }
enum TWO_AND_ONE: int { use ONE; TWO = 2; }

TokenType for reference.

enum TokenType: string {
  NUMERIC_CONSTANT = "Number";
  STRING_CONSTANT = "String";
  CLAUSE = "Clause";
  OPERATOR = "Operator";
  RESERVED = "Reserved";
  PAREN = "Paren";
  SEPARATOR = "Separator";
  SQLFUNCTION = "Function";
  IDENTIFIER = "Identifier";
  NULL_CONSTANT = "Null";
}

Issue template for hack-sql-fake

Please select the options that apply

• Question

Question

QQ: Is it considered rude to push small commits often?
I develop on HHVM4.15 and up. This allows code that typechecks in my version of hh_client, but not on HHVM4.0.4 to go unnoticed until I push. This will cause more Travis jobs (which I assume cost resources to run).

Validate that ascii is ascii, utf8 is valid utf8.

• Feature request
• Question
• Suggestion
• Typechecker errors
• [X ] Incorrect result
• Cripplingly bad performance
• Crash

Incorrect result

The following example:
When doing an AND LIKE query with a plus sign (i.e AND LIKE '%foo+bar%') the plus sign is not escaped and the query does not work correctly.

I have a fix and will be opening a PR.

Issue template for hack-sql-fake

Please select the options that apply

• Feature request
• Question
• Suggestion
• Typechecker errors
• Incorrect result
• Cripplingly bad performance
• Crash

Follow the template for your checked checkbox and then delete the templates.

Question

Would it be considered a bug if the queryf implementation of SQL Fake silently "corrects" errors which cause the real queryf to throw? A lot of strict validation is missing from the SQL Fake implementation and I would love to make it as strict as the real queryf. For example SELECT "hi" throws in the real queryf.

I would love to submit a PR aligning queryf with queryf. This would break BC left, right, and center. But I believe this would be for the better. Would this be appreciated?

Where the row from the main query is referenced inside a subquery, like this:

SELECT * FROM table1 a WHERE NOT EXISTS (SELECT * FROM table2 WHERE a.id = table_1_id)

This will not be trivial to implement

Composer.json requires the exact HHAST version 4.0.4 by using an =4.0.4 version. This blocks the autoload map generation with an exception. If this could be made looser ^4.0.4 the autoload map can be generated again. The typechecker would be happy too.

Issue template for hack-sql-fake

Please select the options that apply

• Feature request
• Question
• Suggestion
• Typechecker errors
• Incorrect result
• Cripplingly bad performance
• Crash

Follow the template for your checked checkbox and then delete the templates.

Question

The queryf implementation of SQL Fake implements modifiers that are not in Hack's hhi. Do you depend on these extra modifiers?