Re: DeleteRule: Nullify vs isMandatory

From: Craig Miskell (cmiskel..lbatross.co.nz)
Date: Sun Feb 02 2003 - 14:34:41 EST

  • Next message: Andriy Shapochka: "Re: Opinion on using DO class as entity id!?"

    Certainly there's currently no code in the deleterule handling that will
    pick up such a case. I think that it should definitely be noticed and
    reported to the user if a map is loaded in such a state, and preferably
    be not possible to set as such in the GUI, or at least is detected on
    save.

    On this note, I wonder about validation of DataMaps in general.
    Currently the GUI does so on save, but I don't think it happens on
    load. Recently Andrus added some "partial loading with feedback" for
    within Modeller (with, IIRC, some nice object-structure for holding
    details of what was wrong). Perhaps this needs to be extended to work
    in a non-GUI, "production" environment. For justification, I see it as
    entirely reasonable for a user to make a change directly in the xml
    (perhaps it's a "small" change, or they don't have access to a GUI jre
    at the time). If they stuff that up, it'd be really nice if Cayenne
    pulled them up on it, rather than just toddling off into the never-never
    land of inconsistency :-)

    Either way, I'll add some consistency checking for the situation below,
    at least for modeller save.

    Craig
     
    On Mon, 2003-02-03 at 06:39, Andriy Shapochka wrote:
    > Seemingly, DeleteRule.NULLIFY is allowed to coexist with the related DbAttribute.isMandatory == true by the current implementation. Consider the scenario:
    > CREATE TABLE A (
    > A_ID INTEGER NOT NULL,
    > CONSTRAINT A_PK PRIMARY KEY (A_ID),
    > );
    >
    > CREATE TABLE B (
    > B_ID INTEGER NOT NULL,
    > A_ID INTEGER NOT NULL,
    > CONSTRAINT B_PK PRIMARY KEY (B_ID),
    > CONSTRAINT B_FK FOREIGN KEY (A_ID) REFERENCES A (A_ID)
    > );
    >
    > If A -> B obj relationship has DeleteRule.NULLIFY Cayenne will try to nullify B.A_ID and the commit will fail. Maybe it would be better to disallow such a situation checking data maps at the early stages and denying combinations like the above mentioned (CASCADE or DENY only allowed in this case). Then it will closely correspond to a straight database modification scenario:
    > 1) Reassign foregn keys to appropriate values manually
    > 2) Delete the dereferenced object in question.
    >
    > What do everybody think? Should it be done or do I overlook some piece of the code already handling this matter?
    >
    > Andriy.
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Sun Feb 02 2003 - 14:35:09 EST