Re: Weird Behaviour with Nullify rule

From: Jorge Sopena (jsopen..idsa.es)
Date: Wed Oct 20 2004 - 09:27:41 EDT

  • Next message: Mike Kienenberger: "Re: Weird Behaviour with Nullify rule"

    Mike Kienenberger wrote:

    >I thought so too since you said the database was correct, but I figured I'd
    >ask just to be sure.
    >
    >I'm no expert in this area, but have you tried looking at the sql log from
    >the point where you delete path3 to the point where you call
    >Company.getListPaths()?
    >
    Looking the log, I've realised that in the first case there isn't any
    query to DB, is to say, the object is found in DataConext.
    Meanwhile in the second case there is a query to DB. why?

    >
    >If Company.getListPaths() is not re-executing the query (generating an SQL
    >query to the database), that could explain the problem. You'd have removed
    >path3 from the database with the delete, but the list itself might still
    >contain a path3 object with PersistentState.TRANSIENT. (Meaning the object
    >has been deleted.).
    >
    >
    No exactly, in the list is still the object path3 but with
    PersistentState.COMITTED.
    When I do the delete, Cayenne tries to remove this object from the List
    but the method List.contains() yields false.
    So Cayenne doesn't remove this object.
    The main problem is when I do the selectQuery to get the object path3, a
    new object is recover from the DB instead of DataContext.
    So, I've got two diferent objects for path3, and the method equals()
    return false.

    Why is "path3" recover from DB if it's in the DataContext?

    >If you are using 1.1RC1, and you try to do a path3.resolveFault() [using the
    >path3 object from the Company.getListPaths()], what happens? If the above
    >situation is the case, you should then get a CayenneRuntimeException()
    >stating "Error resolving fault, no matching row exists in the database for
    >ObjectId." This means that your list contains a deleted item that no
    >longer exists in the database.
    >
    >
    Yes, I've tried it and that error happens.

    >The correct behavior might be to invalidate Company right after deleting
    >Path3 to force it to refetch the data in "getListPaths()"
    >
    >I've had issues in this area recently, and this is how I've solved similar
    >problems, but someone else may point out a better or easier solution (or may
    >even verify that you have located a bug that should be fixed).
    >
    >
    Invalidating the Object Company everything works, but...

    Maybe is a bug, but I'm not sure. May someone else point out a solution?

    Jorge

    >-Mike
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Wed Oct 20 2004 - 09:23:16 EDT