You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Gary Jarrel <ga...@gmail.com> on 2010/05/27 02:42:20 UTC
Relationship Fetching Behavior and Case Sensetivity
Hi Guys,
Another interesting aspect that I came across, perhaps best explained
via a small example
public class Customer {
@Override
public AccountsCustomer getAccountsCustomer() {
AccountsCustomer accCustomer = super.getAccountsCustomer();
try {
accCustomer.getCustomerCode();
} catch (Exception e) {
// we need to aslo check without case sensetivity.
try {
accCustomer =
DataObjectUtils.objectForPK(getObjectContext(),
AccountsCustomer.class, getCustomerCode());
accCustomer.getCustomerCode();
} catch (Exception e1) {
return null;
}
}
return accCustomer;
}
}
I have a Customer class which represents the customer in the web
database, within this class I have getAccountsCustomer() which
actually pulls the record from a customer table in the accounts
database. Now I have no control over the structure of this accounts
database, and the primary keys of the customer table as meaningful
string representations of the customer code.
Now in the getAccountsCustomer method above which I am overriding from
_Customer the first call super.getAccountsCustomer(); actually returns
a hollow object and since I do not want the hollow object but rather a
null I call the getCustomerCode method causing a Fault Exception and
subsequently return null.
This all works fine but only when the customer code cases are the same
in both databases.
So in my test case I reset the customer code in the web customer to
the same as it is in the accounts customer but to lower case and my
getAccountsCustomer() method starts returning null.
This was the case until I put in the second try block which uses
DataObjectUtils (as shown above). The DataObjectUtils.objectForPK
seems to work ignoring cases while the readProperty methods seem to
case sensitive.
Just felt like a bit of an inconsistency.
Cheers,
Gary
Re: Relationship Fetching Behavior and Case Sensetivity
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
> <jb...@gmail.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 <andrus@objectstyle.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
>>>
>>>
>>
>
Re: Relationship Fetching Behavior and Case Sensetivity
Posted by Gary Jarrel <ga...@gmail.com>.
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 <jb...@gmail.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 <an...@objectstyle.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
>>
>>
>
Re: Relationship Fetching Behavior and Case Sensetivity
Posted by Bryan Lewis <jb...@gmail.com>.
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 <an...@objectstyle.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
>
>
Re: Relationship Fetching Behavior and Case Sensetivity
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
On May 27, 2010, at 3:42 AM, Gary Jarrel wrote:
> Hi Guys,
>
> Another interesting aspect that I came across, perhaps best explained
> via a small example
>
> public class Customer {
> @Override
> public AccountsCustomer getAccountsCustomer() {
> AccountsCustomer accCustomer = super.getAccountsCustomer();
>
> try {
> accCustomer.getCustomerCode();
> } catch (Exception e) {
> // we need to aslo check without case sensetivity.
> try {
> accCustomer =
> DataObjectUtils.objectForPK(getObjectContext(),
> AccountsCustomer.class, getCustomerCode());
> accCustomer.getCustomerCode();
> } catch (Exception e1) {
> return null;
> }
> }
>
> return accCustomer;
> }
> }
>
> I have a Customer class which represents the customer in the web
> database, within this class I have getAccountsCustomer() which
> actually pulls the record from a customer table in the accounts
> database. Now I have no control over the structure of this accounts
> database, and the primary keys of the customer table as meaningful
> string representations of the customer code.
>
> Now in the getAccountsCustomer method above which I am overriding from
> _Customer the first call super.getAccountsCustomer(); actually returns
> a hollow object and since I do not want the hollow object but rather a
> null I call the getCustomerCode method causing a Fault Exception and
> subsequently return null.
>
> This all works fine but only when the customer code cases are the same
> in both databases.
>
> So in my test case I reset the customer code in the web customer to
> the same as it is in the accounts customer but to lower case and my
> getAccountsCustomer() method starts returning null.
>
> This was the case until I put in the second try block which uses
> DataObjectUtils (as shown above). The DataObjectUtils.objectForPK
> seems to work ignoring cases while the readProperty methods seem to
> case sensitive.
>
> Just felt like a bit of an inconsistency.
>
> Cheers,
>
> Gary
>