GraphQL where clause not working for ContentItemIndex fields

[naammeinkyahai]

My GraphQL query is

{
  helpContent(where: { contentItemId: "4t4zm5yk5mvx3tmz6stsy2rrn6"}) {
    contentItemId
    displayText
    publishedUtc
  }
}

This is what the generated query looks like for postgresql(tp_ is the table prefix):

SELECT "tp_Document".* FROM "tp_Document" INNER JOIN "tp_ContentItemIndex" ON "tp_ContentItemIndex"."DocumentId" = "tp_Document"."Id" WHERE ("tp_ContentItemIndex"."Published" = $1) AND ("tp_ContentItemIndex"."ContentType" = $2) AND (("ContentItemIndex"."contentItemId" = $3)) ORDER BY "tp_ContentItemIndex"."CreatedUtc" DESC

Using orderBy clause on the same field work well so issue seems to be with where clause only.

There are two issues:

1. Please look at the 3rd where parameter where the ContentItemIndex table doesn't have the appropriate table prefix unlike rest of the items.
2. contentItemId retains the camelCasing instead of the PascalCased column name expected.

I tried debugging the code and my suspicion is
src\OrchardCore\OrchardCore.ContentManagement.GraphQL\Queries\ContentItemsFieldType.cs
For # 1, predicateQuery.CreateAlias("", nameof(ContentItemIndex)); seems to be the issue. We are not determining the right alias.
For # 2, I think orderBy implements a switch statement which changes the case of the fields.

[Jetski5822]

@carlwoodhouse ^^^^

[carlwoodhouse]

Yeah assume this is a bug with table prefixes, I can take a look this week sometime if no one else does

[naammeinkyahai]

@carlwoodhouse Thank you for fix. However, that resolves only 1 of the 2 problems I reported with the query.

1. Please look at the 3rd where parameter where the ContentItemIndex table doesn't have the appropriate table prefix unlike rest of the items.

The following problem is not resolved:

2. contentItemId retains the camelCasing instead of the PascalCased column name expected.

Please reopen this bug as I can't seem to.

[carlwoodhouse]

Urf guessing it’s a Postgres thing :/ the case sensitivity

…

On Thu, 23 May 2019 at 18:12, Abhay Saraf ***@***.***> wrote: @carlwoodhouse <https://github.com/carlwoodhouse> Thank you for fix. However, that resolves only 1 of the 2 problems I reported with the query. 1. Please look at the 3rd where parameter where the ContentItemIndex table doesn't have the appropriate table prefix unlike rest of the items. The following problem is not resolved. 1. contentItemId retains the camelCasing instead of the PascalCased column name expected. Please reopen this bug as I can't seem to. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3684?email_source=notifications&email_token=AADRUECYJWTVGIO7U647ORTPW3F6NA5CNFSM4HOV46HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWC4EYY#issuecomment-495305315>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADRUEBTATJ7HNZCVIPZJV3PW3F6NANCNFSM4HOV46HA> .

[naammeinkyahai]

Yes, this is the log from postgres:

ERROR: column tp_ContentItemIndex.contentItemId does not exist at character 266
HINT: Perhaps you meant to reference the column "tp_ContentItemIndex.ContentItemId".

[naammeinkyahai]

The orderBy implementation in the same file ContentItemsFieldType.cs solves by putting a switch case

[carlwoodhouse]

I’ll take a look later. Need to think about it a bit as the where is more dynamic and can be used with custom indexes, where the casing could be anything.

…

On Thu, 23 May 2019 at 18:16, Abhay Saraf ***@***.***> wrote: The orderBy implementation in the same file ContentItemsFieldType.cs solves by putting a switch case — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3684?email_source=notifications&email_token=AADRUEDRYMP4QBHFJBNX4ETPW3GOLA5CNFSM4HOV46HKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWC4QWQ#issuecomment-495306842>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADRUEF2F426W2BHSBPFKXLPW3GOLANCNFSM4HOV46HA> .