andWhere(), orWhere() - Parameter values overwrite each other

[Rikki Vizcarra]

I'm submitting a...

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

I'm not sure if this is a bug or an actual feature.

Using orWhere() or andWhere() overwrites each others parameter values.

Below is a sample code

    return await this.createQueryBuilder('order')
      .where('order.deleted = :deleted', { deleted: false })
      .andWhere(new Brackets(qb => {
        qb.where('order.status = :status', { status: OrderStatusEnum.UNPROCESSED })
          .orWhere('order.status = :status', { status: OrderStatusEnum.SUCCESS })
      }))
      .getMany();

Both parameter values of :status becomes the "SUCCESS" in this example. Below is the log output.

query: SELECT `order`.`created_at` AS `order_created_at`, `order`.`updated_at` AS `order_updated_at`, `order`.`id` AS `order_id`, `order`.`order_key` AS `order_order_key`, `order`.`reference_key` AS `order_reference_key`, `order`.`delivery_type` AS `order_delivery_type`, `order`.`status` AS `order_status`, `order`.`payment_return_id` AS `order_payment_return_id`, `order`.`payment_redirect_url` AS `order_payment_redirect_url`, `order`.`total_price` AS `order_total_price`, `order`.`currency` AS `order_currency`, `order`.`user_id` AS `order_user_id`, `order`.`address_id` AS `order_address_id`, `order`.`branch_id` AS `order_branch_id` FROM `orders` `order` WHERE order.deleted = ? AND (`order`.`status` = ? OR `order`.`status` = ?)
 -- PARAMETERS: [false,"SUCCESS","SUCCESS"]

If I switch the values, this is what happens
CODE:

    return await this.createQueryBuilder('order')
      .where('order.deleted = :deleted', { deleted: false })
      .andWhere(new Brackets(qb => {
        qb.where('order.status = :status', { status: OrderStatusEnum.SUCCESS })
          .orWhere('order.status = :status', { status: OrderStatusEnum.UNPROCESSED })
      }))
      .getMany();

OUTPUT:

query: SELECT `order`.`created_at` AS `order_created_at`, `order`.`updated_at` AS `order_updated_at`, `order`.`id` AS `order_id`, `order`.`order_key` AS `order_order_key`, `order`.`reference_key` AS `order_reference_key`, `order`.`delivery_type` AS `order_delivery_type`, `order`.`status` AS `order_status`, `order`.`payment_return_id` AS `order_payment_return_id`, `order`.`payment_redirect_url` AS `order_payment_redirect_url`, `order`.`total_price` AS `order_total_price`, `order`.`currency` AS `order_currency`, `order`.`user_id` AS `order_user_id`, `order`.`address_id` AS `order_address_id`, `order`.`branch_id` AS `order_branch_id` FROM `orders` `order` WHERE order.deleted = ? AND (`order`.`status` = ? OR `order`.`status` = ?)
 -- PARAMETERS: [false,"UNPROCESSED","UNPROCESSED"]

Expected behavior

I was expecting that it won't overwrite each others parameter values.

Minimal reproduction of the problem with instructions

You can do any combinations of andWhere() or orWhere() to your test.

What is the motivation / use case for changing the behavior?

It's it more logical, especially for an orWhere() not to overwrite each others parameter values.

Environment

[System Information]
OS Version     : macOS Catalina
NodeJS Version : v10.20.1
NPM Version    : 6.14.4 

[Nest CLI]
Nest CLI Version : 7.1.4 

[Nest Platform Information]
platform-express version : 7.0.9
platform-fastify version : 7.0.9
passport version         : 7.0.0
swagger version          : 4.5.3
typeorm version          : 7.0.0
common version           : 7.0.9
core version             : 7.0.9
jwt version              : 7.0.0

[Kamil Mysliwiec]

Please, report typeorm issues in this repo https://github.com/typeorm/typeorm

[Christopher Hall]

For anyone who comes to this in the future: The unexpected behavior occurs because the parameter status is used twice in the query. Using unique names fixes the issue.

Just spent the last hour figuring this out :)

[Rahul Anthony Mitra]

Thank you @hallgchris I just ran into this issue and found your solution. It's strange that typeorm does not throw an error here but proceeds to overwrite the query condition.