Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2405

Changing strategy generates bad query.

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      For (unit, acceptance, functional) testing purpose I need to change the strategy of my GameStuff Entity class.

      In previous version is was using php instruction below, but since doctrine orm 2.3, it doesn't work anymore.

      $orm->getClassMetaData('Entities\GameStuff')->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

      will trigger:

      Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO vbank_accounts (game_id, updated_at, created_at) VALUES (?, ?, ?)' with params

      {"1":1000010, "2":0,"3":"2013-04-19 17:16:05","4":"2013-04-19 17:16:05"}

      :

      SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

        Activity

        Hide
        Van Rotemberg added a comment - - edited

        @marco pivetta

        The generation of the actual exception comes from DBALException on the query excetion and point a bad generated query (Invalid parameter number),
        when the problem comes from setting ClassMetada, and concerns a problem of cache generated after loadClassMetadata.

        Adding an exception is just the fast way pointing where the problem comes from and that "setting metadata after loadMetadata is not supported anymore". (It will spare developper's time that used to set metadata, but also help future contribution)

        > Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...
        Note: BTW, my favorite solution would be to fix it (re-generate cache, or edit cache, or disable cache or whatever)

        Show
        Van Rotemberg added a comment - - edited @marco pivetta The generation of the actual exception comes from DBALException on the query excetion and point a bad generated query (Invalid parameter number), when the problem comes from setting ClassMetada, and concerns a problem of cache generated after loadClassMetadata. Adding an exception is just the fast way pointing where the problem comes from and that "setting metadata after loadMetadata is not supported anymore". (It will spare developper's time that used to set metadata, but also help future contribution) > Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ... Note: BTW, my favorite solution would be to fix it (re-generate cache, or edit cache, or disable cache or whatever)
        Hide
        Marco Pivetta added a comment -

        Almost every interaction with metadata outside the `loadClassMetadata` event will cause unexpected problems. I don't think throwing an exception there helps in any way.

        Show
        Marco Pivetta added a comment - Almost every interaction with metadata outside the `loadClassMetadata` event will cause unexpected problems. I don't think throwing an exception there helps in any way.
        Hide
        Van Rotemberg added a comment -

        > The problem is that changing ClassMetadata after generating it from the cache is not really supported

        Yeah, it is a problem indeed, why set ticket status to resolved ?
        Do you think it's normal to have a public method that trigger a fatal error ?

        Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...

        Show
        Van Rotemberg added a comment - > The problem is that changing ClassMetadata after generating it from the cache is not really supported Yeah, it is a problem indeed, why set ticket status to resolved ? Do you think it's normal to have a public method that trigger a fatal error ? Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...
        Hide
        Benjamin Eberlei added a comment -

        The problem is that changing ClassMetadata after generating it from the cache is not really supported and depends on the Internal State of other classes. Have you tried creating a completly new EntityManager and then directly setting this? It could be that the SQL for the entity was already generated inside Doctrine, with the ID Generator information at IDENTITY_AUTO.

        Show
        Benjamin Eberlei added a comment - The problem is that changing ClassMetadata after generating it from the cache is not really supported and depends on the Internal State of other classes. Have you tried creating a completly new EntityManager and then directly setting this? It could be that the SQL for the entity was already generated inside Doctrine, with the ID Generator information at IDENTITY_AUTO.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Van Rotemberg
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: