Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior of getFormattedQuery() #3534

Closed
montycb opened this issue Sep 23, 2022 · 4 comments
Closed

Unexpected behavior of getFormattedQuery() #3534

montycb opened this issue Sep 23, 2022 · 4 comments

Comments

@montycb
Copy link
Contributor

montycb commented Sep 23, 2022

Calling getFormattedQuery() after a join with pagination, causes subsequent QueryBuilder calls to insert SQL Statements in the wrong location.

I have included a minimal Example. Both qb and qb2 should build the same query, hover the getFormattedQuery() call modifies the result.

The DISABLE_PAGINATE flag can be used as a workaround, however I expect a getter function to not modify the underlying object.

Testcase

import { Collection, Entity, ManyToOne, MikroORM, OneToMany, PrimaryKey } from "@mikro-orm/core";
import { SqliteDriver } from "@mikro-orm/sqlite";

@Entity()
export class A {
  @PrimaryKey()
  id!: string;

  @OneToMany({ entity: 'B', mappedBy: 'ref_a'})
  ref_b = new Collection<B>(this);
}

@Entity()
export class B {
  @PrimaryKey()
  id!: string;

  @ManyToOne(() => A)
  ref_a!: A;
}

test('sqlite', async () => {
  const orm: MikroORM<SqliteDriver> = await MikroORM.init({
    entities: [A, B],
    dbName: ':memory:',
    type: 'sqlite',
  });

  const qb = orm.em.createQueryBuilder(A, 'alias_a')
    .leftJoin('ref_b', 'alias_b')
    .limit(5)

  qb.getFormattedQuery() // finalizes query => paginate wrap
  qb.andWhere({ id: 5 })
  const a = qb.getFormattedQuery()

  const qb2 = orm.em.createQueryBuilder(A, 'alias_a')
    .leftJoin('ref_b', 'alias_b')
    .limit(5)

  qb2.andWhere({ id: 5 })
  const b = qb2.getFormattedQuery()
  expect(a).toBe(b);

  await orm.close(true);
})
@B4nan
Copy link
Member

B4nan commented Sep 23, 2022

Fixing this might require quite deep refactoring of how the QB works, as we would need to cache the calls and evaluate everything later, right now there is no easy way to reset things to "before finalization" state.

But in the long run it would make sense for sure, cloning would be much simpler too.

@montycb
Copy link
Contributor Author

montycb commented Sep 26, 2022

Maybe a warning could be added to the documentation until this gets fixed?

@B4nan
Copy link
Member

B4nan commented Sep 26, 2022

We could probably throw if you try to modify a finalized QB, adding notes to docs wont help much, it would be still quite hidden.

@montycb
Copy link
Contributor Author

montycb commented Sep 27, 2022

I think that would be a good Idea, you really shouldn't be able to modify a finalized query.

@B4nan B4nan closed this as completed in b23f015 Oct 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants