Re: Relationship Fetching Behavior and Case Sensetivity

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri May 28 2010 - 06:40:16 UTC

  • Next message: Andrus Adamchik: "Re: More on caching"

    Just logged a Jira: https://issues.apache.org/jira/browse/CAY-1437

    On May 28, 2010, at 3:55 AM, Gary Jarrel wrote:

    > I think that would be a good idea as well... It's interesting but in
    > my case when I try to resolve a relationship I get a hollow object,
    > hence my code within the JSPs such as <c:if test="empty
    > customer.salesRep"> ... </c:if> is not executing because although the
    > customer may not have a salesRep the null test does not return true
    > because the object is hollow.
    >
    > I will trace though the test case which I mentioned above and see if I
    > can pull some database logs to see what is going on.
    >
    > Cheers,
    >
    > Gary
    >
    > On Thu, May 27, 2010 at 11:17 PM, Bryan Lewis
    > <jbryanlewi..mail.com> wrote:
    >> Tossing in my vote... yes, it would be nice to have an easier way to
    >> override the fault resolution. We've had referential integrity
    >> problems for
    >> a long time, dealing with a legacy database. My fix has been to
    >> subclass
    >> DataContext and catch the FaultFailureException in
    >> prepareForAccess().
    >> That's not so bad, but pluggable would be a bit nicer.
    >>
    >>
    >> On Thu, May 27, 2010 at 4:20 AM, Andrus Adamchik <andru..bjectstyle.org
    >> >wrote:
    >>
    >>> Do you have DB operation logs for both cases and are they
    >>> generating the
    >>> same query and bringing back 1 object?
    >>>
    >>> If that's the case (and I suspect it is), there could be something
    >>> about
    >>> ObjectId matching in memory (e.g. when we guess an ObjectId with
    >>> incorrect
    >>> case, and then bring back a new object that has ObjectId with DB-
    >>> provided
    >>> case, "equals" method no longer works on ObjectIds and we are
    >>> making some
    >>> incorrect conjectures...
    >>>
    >>> On a general note, as I personally had to deal with referential
    >>> integrity
    >>> issues a lot myself, I feel like having a pluggable fault resolution
    >>> strategy might be a good idea going forward. Maybe something for
    >>> 3.1 (which
    >>> is DI-based and can help making things pluggable).
    >>>
    >>> Andrus
    >>>
    >>>
    >>
    >



    This archive was generated by hypermail 2.0.0 : Fri May 28 2010 - 06:40:49 UTC