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 - 00:55:54 UTC