Cayenne
  1. Cayenne
  2. CAY-436

In modeler, change default object relationship delete rule

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0M5, 3.0
    • Component/s: Core Library, Modeler
    • Labels:
      None
    • Environment:
      winxp, M7

      Description

      Should be good to change default delete rules for object relationships, one to many - cascade, and vice versa - to nullify. I think it's the rules used mostly for these relationships.
      And the best thing would be to have configurable options for these, but that's more complex.

      1. patch-CAY-436.txt
        20 kB
        Andrey Razumovsky

        Activity

        Hide
        Kevin Menard added a comment -

        Applied Andrey's patch with minor clean-ups.

        Show
        Kevin Menard added a comment - Applied Andrey's patch with minor clean-ups.
        Hide
        Kevin Menard added a comment -

        All in all, this looks pretty good. A couple questions:

        1) In DbLoaderHelper, is there any reason that you need to explicitly update the ObjEntity? Or rather, is there a reason that your observer pattern fails to work here?

        2) Is there a reason that the observer pattern fails in ObjRelationshipInfoModel#savePath?

        I may be looking at the code wrong, but it strikes me that the EntityMergeListener or something similar could be used in such a way that you don't actually have to hook in explicit updates in so many places.

        Show
        Kevin Menard added a comment - All in all, this looks pretty good. A couple questions: 1) In DbLoaderHelper, is there any reason that you need to explicitly update the ObjEntity? Or rather, is there a reason that your observer pattern fails to work here? 2) Is there a reason that the observer pattern fails in ObjRelationshipInfoModel#savePath? I may be looking at the code wrong, but it strikes me that the EntityMergeListener or something similar could be used in such a way that you don't actually have to hook in explicit updates in so many places.
        Hide
        Andrey Razumovsky added a comment -

        implementation of the feature.

        Show
        Andrey Razumovsky added a comment - implementation of the feature.
        Hide
        Andrey Razumovsky added a comment -

        It's tricky with reverse engeneering: seems we can only detect delete rule in only one direction (i mean the DELETE_RULE column of returned getExportedKeys() query). So we will have to set default value to reverse relationship anyways.
        Also it requries some DbLoader (or probably Db- and ObjRelationships) since we're creating DbRels and not ObjRels from database in DbLoader. So ithink that if we want to include delete rule to the "work field" of Cayenne, we should go futher, and make the rule part of DbRelationship, so that we could generate the schema properly too.

        As of the defaults, actually I'd prefer DENY of one-to-many and NULLIFY vice versa So I'll probably add two more preferences in CM and set NO ACTION as default so that nothing would change for users without their activity

        Show
        Andrey Razumovsky added a comment - It's tricky with reverse engeneering: seems we can only detect delete rule in only one direction (i mean the DELETE_RULE column of returned getExportedKeys() query). So we will have to set default value to reverse relationship anyways. Also it requries some DbLoader (or probably Db- and ObjRelationships) since we're creating DbRels and not ObjRels from database in DbLoader. So ithink that if we want to include delete rule to the "work field" of Cayenne, we should go futher, and make the rule part of DbRelationship, so that we could generate the schema properly too. As of the defaults, actually I'd prefer DENY of one-to-many and NULLIFY vice versa So I'll probably add two more preferences in CM and set NO ACTION as default so that nothing would change for users without their activity
        Hide
        Kevin Menard added a comment -

        I don't know. While NULLIFY is likely the most used, I think DENY might be a better default since it forces the user to have to make a decision. I do agree that No Action is not the best default, however.

        Show
        Kevin Menard added a comment - I don't know. While NULLIFY is likely the most used, I think DENY might be a better default since it forces the user to have to make a decision. I do agree that No Action is not the best default, however.
        Hide
        Andrus Adamchik added a comment -

        a agree - we need better defaults. Also we may want to figure out the rules on reverse engineering.

        Show
        Andrus Adamchik added a comment - a agree - we need better defaults. Also we may want to figure out the rules on reverse engineering.

          People

          • Assignee:
            Kevin Menard
            Reporter:
            weidox
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development