vrana/notorm

Column Ambiguity on Multiple Join

Closed this issue · 4 comments

If I have 2 tables with the same column name and use them together as a where condition, then it will triggers ambigue error from MySql.

Take a look this sample tables below:

  • user : id, name, email
  • question : id, user_id, text, html
  • answer : id, user_id, question_id, text, html

If I do this call, then it will trigger the error:
$db->question()->where('answer:user_id = ?', 1)->where('user_id = ?', 2);

The first where statement will be generated with the right table prefix, while the second where statement will be generated without any prefix and causes ambiguity.

EDIT: I revised the notation to use semicolon, instead of dot, for referencing column from question to answer.

I added additional feature to pass NotORM_Literal into where clause, so that whatever inside will not be parsed, except for parameters. From emergency testing it will raise PDO exception due to invalid argument number, so I revert back using it without any parameters at the moment. Please advice!

I modified line 365 by adding this code below:

    if($condition instanceof NotORM_Literal) {
        $condition = $condition->__toString();
        $this->parameters = array_merge($this->parameters, $condition->parameters);
    } elseif ($args != 2 || strpbrk($condition, "?:")) { // where("column < ? OR column > ?", array(1, 2))

Just use question.user_id instead of user_id.

Sorry to reopen this issue, but I just check that it can't be done if I'm using table prefix.

$db = new NotORM($pdo, new NotORM_Structure_Convention(
    $primary = 'id',
    $foreign = '%s_id',
    $table = '%s',
    $prefix = 'some_prefix_'
), new NotORM_Cache_Include(CACHE_DIR));

Instead of using question.user_id, I have to use some_prefix_question.user_id, which kinda beat the purpose of having prefixed table.

I'm a bit confused now, but it doesn't seems to work with some_prefix_question.user_id, because NotORM is trying to join the existing question table with some_prefix_question table.