Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-BETA2
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      There should be a CLI task "validate-mapping" or similar that reads in the metadata of all configured, mapped classes and processes them one-by-one, looking for errors in the mapping. For example, it is easy to detect that way when there is an association mapped with mappedBy but the other side does not have inversedBy specified (or there is not even another side...) . We can not make such strict validations during runtime for performance reasons, so a specific CLI task can be a great help during development for troubleshooting.

        Activity

        Roman S. Borschel created issue -
        Hide
        Benjamin Eberlei added a comment -

        We also need this to check in development if the current database schema equals the current metadata mapping. Possibly extracting all the logic of this into a Service Object so that users can include this in Phing or similar build processes.

        Show
        Benjamin Eberlei added a comment - We also need this to check in development if the current database schema equals the current metadata mapping. Possibly extracting all the logic of this into a Service Object so that users can include this in Phing or similar build processes.
        Roman S. Borschel made changes -
        Field Original Value New Value
        Fix Version/s 2.0 [ 10021 ]
        Hide
        Roman S. Borschel added a comment -

        I interpret that as you volunteering

        Show
        Roman S. Borschel added a comment - I interpret that as you volunteering
        Roman S. Borschel made changes -
        Assignee Roman S. Borschel [ romanb ] Benjamin Eberlei [ beberlei ]
        Hide
        Marc Hodgins added a comment -

        It would also be helpful if the task could look for lifecycle callback annotations in the methods and raise a warning if the class does not have a @HasLifeCycleCallbacks annotation.

        Show
        Marc Hodgins added a comment - It would also be helpful if the task could look for lifecycle callback annotations in the methods and raise a warning if the class does not have a @HasLifeCycleCallbacks annotation.
        Hide
        Benjamin Eberlei added a comment -

        Hm this last one is a bit complicated, one would need to check if the annotation driver is used, instantiate your own reader and check for this error.

        Show
        Benjamin Eberlei added a comment - Hm this last one is a bit complicated, one would need to check if the annotation driver is used, instantiate your own reader and check for this error.
        Hide
        Roman S. Borschel added a comment - - edited

        In the context of DDC-567 it would also be nice to validate that all referenced column names are primary key columns.

        ps. If anyone is curious why referencedColumnName then not always automatically points to the primary key column of the other class, its just not doable in an efficient way I think. referencedColumnName defaults to the hardcoded "id" name, because each class metadata must be able to be loaded independently without loading others (inheritance being an exception). If we start "guessing" default values by looking at other classes, we quickly load the metadata for huge parts (or all) of the mapping of the domain model on each request. At least during development without a persistent cache this would be a major pain and slowdown.

        Show
        Roman S. Borschel added a comment - - edited In the context of DDC-567 it would also be nice to validate that all referenced column names are primary key columns. ps. If anyone is curious why referencedColumnName then not always automatically points to the primary key column of the other class, its just not doable in an efficient way I think. referencedColumnName defaults to the hardcoded "id" name, because each class metadata must be able to be loaded independently without loading others (inheritance being an exception). If we start "guessing" default values by looking at other classes, we quickly load the metadata for huge parts (or all) of the mapping of the domain model on each request. At least during development without a persistent cache this would be a major pain and slowdown.
        Hide
        Benjamin Eberlei added a comment -

        @Roman - I just checked for "referencedColumnName" in the code, aswell as for their descendants during metadata ClassMetadata generation.

        It seems they are not used "that" much throughout the code, would a lookuup to the targetEntity work? We could get rid of this attribute then...

        Show
        Benjamin Eberlei added a comment - @Roman - I just checked for "referencedColumnName" in the code, aswell as for their descendants during metadata ClassMetadata generation. It seems they are not used "that" much throughout the code, would a lookuup to the targetEntity work? We could get rid of this attribute then...
        Hide
        Roman S. Borschel added a comment - - edited

        @Benjamin: We can not get rid of it anyway because of composite keys I think.

        Like I said, a lookup on the targetEntity would potentially trigger a huge cascade of metadata loading throughout the whole domain model. Then the targetEntity has associations and so on and so on.

        Show
        Roman S. Borschel added a comment - - edited @Benjamin: We can not get rid of it anyway because of composite keys I think. Like I said, a lookup on the targetEntity would potentially trigger a huge cascade of metadata loading throughout the whole domain model. Then the targetEntity has associations and so on and so on.
        Hide
        Benjamin Eberlei added a comment -

        This was implemented in the latest commit.

        Show
        Benjamin Eberlei added a comment - This was implemented in the latest commit.
        Benjamin Eberlei made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0-BETA2 [ 10050 ]
        Fix Version/s 2.0 [ 10021 ]
        Resolution Fixed [ 1 ]
        Benjamin Eberlei made changes -
        Workflow jira [ 11212 ] jira-feedback [ 14385 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 14385 ] jira-feedback2 [ 16249 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 16249 ] jira-feedback3 [ 18502 ]

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-515, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Roman S. Borschel
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: