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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

[MongoDB] Insensitive filters don't exclude undefineds #14664

Closed
Weakky opened this issue Aug 4, 2022 · 0 comments 路 Fixed by prisma/prisma-engines#3088
Closed

[MongoDB] Insensitive filters don't exclude undefineds #14664

Weakky opened this issue Aug 4, 2022 · 0 comments 路 Fixed by prisma/prisma-engines#3088
Assignees
@Weakky
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. tech/engines Issue for tech Engines. topic: mongodb
Milestone
4.3.0

Comments

@Weakky
Copy link
Member

Weakky commented Aug 4, 2022

Overview

Consider the following datamode 馃憞l,

model User {
  id Int @id @map("_id")
  name? String
}

the following dataset 馃憞,

[
  { id: 1, name: "toto" },
  { id: 2 },
]

And the following query 馃憞:

await prisma.user.findMany({ where: { name: { lt: "z", mode: insensitive } } })

It should return:

[
  { id: 1, name: "toto" },
]

But it returns:

[
  { id: 1, name: "toto" },
  { id: 2 },
]
@Weakky Weakky added bug/2-confirmed Bug has been reproduced and confirmed. tech/engines Issue for tech Engines. team/client Issue for team Client. topic: mongodb labels Aug 4, 2022
@Weakky Weakky mentioned this issue Aug 4, 2022
Merged
2 tasks
@janpio janpio transferred this issue from prisma/prisma-engines Aug 4, 2022
@do4gr do4gr added the kind/bug A reported bug. label Aug 5, 2022
@Weakky Weakky self-assigned this Aug 23, 2022
SevInf added a commit that referenced this issue Aug 24, 2022
@SevInf
feat(client): Integrate field references
3f8e0bd 
Integrates engine changes from prisma/prisma-engines#3088.

Generates new kinds of types from DMMF: field references. Those
types are generic and parametrized with 2 parameters:
- Model name
- Type name
Those 2 generic types allow us to have compile-time error in case
incorrect/incompatible column reference is used.

As a result of this change, some of the input types have also became
generic. Logic for deciding if type needs generic `$PrismaModel`
paramter is following:
- if `meta.source` property is set, type never requires generic
  parameter. This new property was added to DMMF to indicate that the
  type is derived from specific model. If that's the case, we know which
  model field references use for sure and don't need generic parameters
- Otherwise, if input type has any fields that accept field references,
  it requires generic paramters. This logic also applies to nested
  object types: if object type needs generic parameter, all objects
  including the field of this type will need one as well, unless
  `meta.source` is known.

In runtime, `model.fields` implemented as a proxy, returning
wrapper objects for references. For runtime validation, we also need to
know model name, this particular field refers to.

Fixes #14664
SevInf added a commit that referenced this issue Aug 24, 2022
@SevInf
feat(client): Integrate field references
3634563 
Integrates engine changes from prisma/prisma-engines#3088.

Generates new kinds of types from DMMF: field references. Those
types are generic and parametrized with 2 parameters:
- Model name
- Type name
Those 2 generic types allow us to have compile-time error in case
incorrect/incompatible column reference is used.

As a result of this change, some of the input types have also became
generic. Logic for deciding if type needs generic `$PrismaModel`
paramter is following:
- if `meta.source` property is set, type never requires generic
  parameter. This new property was added to DMMF to indicate that the
  type is derived from specific model. If that's the case, we know which
  model field references use for sure and don't need generic parameters
- Otherwise, if input type has any fields that accept field references,
  it requires generic paramters. This logic also applies to nested
  object types: if object type needs generic parameter, all objects
  including the field of this type will need one as well, unless
  `meta.source` is known.

In runtime, `model.fields` implemented as a proxy, returning
wrapper objects for references. For runtime validation, we also need to
know model name, this particular field refers to.

Fixes #14664
@SevInf SevInf mentioned this issue Aug 24, 2022
Merged
SevInf added a commit that referenced this issue Aug 25, 2022
@SevInf
feat(client): Integrate field references
c2f4558 
Integrates engine changes from prisma/prisma-engines#3088.

Generates new kinds of types from DMMF: field references. Those
types are generic and parametrized with 2 parameters:
- Model name
- Type name
Those 2 generic types allow us to have compile-time error in case
incorrect/incompatible column reference is used.

As a result of this change, some of the input types have also became
generic. Logic for deciding if type needs generic `$PrismaModel`
paramter is following:
- if `meta.source` property is set, type never requires generic
  parameter. This new property was added to DMMF to indicate that the
  type is derived from specific model. If that's the case, we know which
  model field references use for sure and don't need generic parameters
- Otherwise, if input type has any fields that accept field references,
  it requires generic paramters. This logic also applies to nested
  object types: if object type needs generic parameter, all objects
  including the field of this type will need one as well, unless
  `meta.source` is known.

In runtime, `model.fields` implemented as a proxy, returning
wrapper objects for references. For runtime validation, we also need to
know model name, this particular field refers to.

Fixes #14664
@janpio janpio added this to the 4.3.0 milestone Aug 27, 2022
SevInf added a commit that referenced this issue Aug 29, 2022
@SevInf @danstarns @millsp
feat(client): Integrate field references (#14982)
83100ad 
* feat(client): Integrate field references

Integrates engine changes from prisma/prisma-engines#3088.

Generates new kinds of types from DMMF: field references. Those
types are generic and parametrized with 2 parameters:
- Model name
- Type name
Those 2 generic types allow us to have compile-time error in case
incorrect/incompatible column reference is used.

As a result of this change, some of the input types have also became
generic. Logic for deciding if type needs generic `$PrismaModel`
paramter is following:
- if `meta.source` property is set, type never requires generic
  parameter. This new property was added to DMMF to indicate that the
  type is derived from specific model. If that's the case, we know which
  model field references use for sure and don't need generic parameters
- Otherwise, if input type has any fields that accept field references,
  it requires generic paramters. This logic also applies to nested
  object types: if object type needs generic parameter, all objects
  including the field of this type will need one as well, unless
  `meta.source` is known.

In runtime, `model.fields` implemented as a proxy, returning
wrapper objects for references. For runtime validation, we also need to
know model name, this particular field refers to.

Fixes #14664

* Use nested tests structure

* package: bump-engines 4.3.0-30.feat-column-comparison-1f0b45043e4b824d5d4d9bc32a8819ae9d658bb6

* test: update snapshot

* bump engines

* Update packages/client/src/runtime/core/model/applyModel.ts

Co-authored-by: pierre <pierreantoine.urvoy@gmail.com>

* Address some of the review comments

* Fix type tests

* Update snapshots

Co-authored-by: Daniel Starns <danielstarns@hotmail.com>
Co-authored-by: Pierre-Antoine Mills <pierreantoine.urvoy@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Weakky Weakky

Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. tech/engines Issue for tech Engines. topic: mongodb
Projects
None yet
Milestone
4.3.0
Development

Successfully merging a pull request may close this issue.

feat: support referencing field in filters prisma/prisma-engines
3 participants
@janpio @do4gr @Weakky