GraphQL auto schema findQuery is not generated for classes named in plural

Issue Description

GraphQL auto schema gets generated only partially for classes named in plural. get seems to work fine, but findQuery is not available at all.

Steps to reproduce

Create a collection named in plural, eg Data, UserData, Comments etc

Expected Results

Be able to issue find GQL query

Actual Outcome

Schema generated only partially

Environment Setup

Server
- parse-server version (Be specific! Don't say 'latest'.) : 3.9.0

Logs/Trace

n/a

I understand this is a bad practice to name collection in plural (i have some legacy code), but for sure it's possible to handle by adding a few lines of code in generator for such edge cases. (when pluralize's output equals className)

I'm looking forward to add a PR for that but i'm not sure what would be a better way to name it. commentses / comments_ / commentss / ... ?

Yes if your collection is named in plural the Parse GraphQL Server could not auto generate the plural version

I will take a look to our plural generation to check if we can add an auto renaming (plural to single) on plural classes

Yes if your collection is named in plural the Parse GraphQL Server could not auto generate the plural version

I will take a look to our plural generation to check if we can add an auto renaming (plural to single) on plural classes

I think 'depluralizing' won't work in 100% cases. Linguistic approach should be 'best effort' for nice readability rather a strict rule. There are other languages and letters combinations that will mislead english 'pluralizer' causing unexpected behavior. In case when pluralize input==output some fallback behavior is needed. Seems adding an extra symbol and checking the result against already established collection names is necessary to be on a safe side.

@BufferUnderflower

@BufferUnderflower thanks for the PR ! 😄
Can we close this one?

Pardon me opening closed issue

How can I use auto schema for dockerized parse and prevent this message:
Query ${fieldName} could not be added to the auto schema because it collided with an existing field.

@nasermirzaei89

Hi @nasermirzaei89, what is your parse classes names ?

@nasermirzaei89

Hi @nasermirzaei89, what is your parse classes names ?

Media

You only have on class into your app ?
Your class media should be generated correctly, the result will be media and medias .
The issue seems to be more deeper.

Are you sure to run the latest version of the parse docker image ?

Can you provide your command line / config that you use to start the server ?

the problem is when the auto schema generates. for example for Item class, list method will be items and findById will be item. but for Media class those are the same, so there will be a conflict when autoschema wants to add list items. both are media.
there are more words in English that plural is the same as the singular.
there should be a way that is compatible with docker envs to set custom names for graphql queries, maybe.

server:
    image: parseplatform/parse-server:4.2.0
    ports:
      - 1337:1337
    depends_on:
      - mongo
    environment:
      PARSE_SERVER_APPLICATION_ID: appId
      PARSE_SERVER_MASTER_KEY: masterKey
      PARSE_SERVER_DATABASE_URI: mongodb://mongo/xonyagar
      PARSE_SERVER_JAVASCRIPT_KEY: javascriptKey
      PARSE_SERVER_REST_API_KEY: restApiKey
      PARSE_SERVER_MAX_UPLOAD_SIZE: 100mb
      PORT: 1337
      PARSE_SERVER_HOST: 0.0.0.0
      PARSE_SERVER_MOUNT_PATH: /parse
      PARSE_SERVER_MOUNT_GRAPHQL: 1
      PARSE_PUBLIC_SERVER_URL: http://localhost:1337/parse

This is a part of auto generated graphql schema:

...
"The health query can be used to check if the server is up and running."
    health: Boolean!
    "The link query can be used to get an object of the Link class by its id."
    link(
        "This is the object id. You can use either the global or the object id."
        id: ID!,
        "The read options for the query to be executed."
        options: ReadOptionsInput
    ): Link!
    "The links query can be used to find objects of the Link class."
    links(
        after: String,
        before: String,
        first: Int,
        last: Int,
        "The read options for the query to be executed."
        options: ReadOptionsInput,
        "The fields to be used when sorting the data fetched."
        order: [LinkOrder!],
        "This is the number of objects that must be skipped to return."
        skip: Int,
        "These are the conditions that the objects need to match in order to be found."
        where: LinkWhereInput
    ): LinkConnection!
    "The media query can be used to get an object of the Media class by its id."
    media(
        "This is the object id. You can use either the global or the object id."
        id: ID!,
        "The read options for the query to be executed."
        options: ReadOptionsInput
    ): Media!
...

as you see media list isn't generated because of conflict in name with media get! but, for example links and link generated successfully!

Oh I see, the pluralize system will work in 97% of use cases I guess ( I have many parse server with hundred of classes and I did not encounter this type of error)

Did you take a look on the pull request linked above to activate aliases and get rid off this issue ?

I see 2 solutions here for your use case:

Build your own docker image with the aliases option on the GraphQL parse server
Migrate the class to another name that pluralize will support correctly

What do you think about this ?

I already used the second solution MediaRecord. But it would be awesome to manage this by using environment configs in the official parse-server docker image.
DONE!

I think your suggestion is interesting, we have many exemple on how to support option via Env vars. Since we are in open source project, each addition is welcome. I invite you to create a parse-server fork and may be start a pull request ? :)
Sounds good for you ?

I interested in contributing to projects I use. I will do that for dear parse community as soon as possible.

@nasermirzaei89

@nasermirzaei89 I am running into the same problem. Many of my classes have the suffix LocalizedData. Data is the same in singular and plural. Other classes end in Content, same problem. I looked at the plualization code, and it's hard to imagine a fallback for these scenarios.

If we don't fix this, people will continue running into this issue in the future. Since a migration is not always possible, that can be pretty discouraging. I think your idea with the environment variables is a good fix for when people run into issues, but it would of course be better if they'd just not run into them.

What prevents us from adding a suffix to the name if the singular and plural are identical? Something like "All", "Items" or "Records"? That could still clash with another name but it's much less likely to happen.

I think this idea makes sense. I am re-opening the issue. Would you be willed to tackle this one?

GraphQL: Add "Objects" suffix to schema find query classname if plura…

@davimacedo

I tried making my first contribution on the weekend, but couldn't manage to test everything locally. I'm happy to give it another shot though. @davimacedo, maybe you can help me out in setting up the development environment? I already asked in Slack in the #parse-server channel: https://parseopensource.slack.com/archives/C0TS8BRRV/p1604763010023300

Just answered you in slack. Take a look if that helps and let me know.

Navigation Menu

Repository navigation

GraphQL auto schema findQuery is not generated for classes named in plural #6218

Issue Description

Steps to reproduce

Expected Results

Actual Outcome

Environment Setup

Logs/Trace

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

GraphQL auto schema findQuery is not generated for classes named in plural #6218

Description

Issue Description

Steps to reproduce

Expected Results

Actual Outcome

Environment Setup

Logs/Trace

Activity

Moumouls commented on Nov 15, 2019

BufferUnderflower commented on Nov 15, 2019

Moumouls commented on Dec 5, 2019

nasermirzaei89 commented on Jul 8, 2020

Moumouls commented on Jul 14, 2020

nasermirzaei89 commented on Jul 14, 2020

Moumouls commented on Jul 14, 2020

nasermirzaei89 commented on Jul 14, 2020

nasermirzaei89 commented on Jul 14, 2020

Moumouls commented on Jul 14, 2020

nasermirzaei89 commented on Jul 14, 2020

Moumouls commented on Jul 14, 2020

nasermirzaei89 commented on Jul 14, 2020

julianvogels commented on Nov 6, 2020

davimacedo commented on Nov 6, 2020

julianvogels commented on Nov 9, 2020

davimacedo commented on Nov 10, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions