Hollow just means it hasn't been resolved.
You say that when you resolveFault on it, it throws an exception?
Can you post a full stack track for one of those exceptions?
I don't know if my knowledge level is high enough to be of help, but the
more information you make available, the better your chances that someone
will be able to respond.
I'm still running 1.1M5, so I'm not using the latest code, but I've never
needed to manually resolveFault() other than in the special-case situation
mentioned before. I can't actually think of any other place in my code
where I access (rather than just set) non-mandatory relationships, however.
-Mike
Orion Fields <ofield..martserv.com> wrote:
> I do check for null, but it never is. There is always an object
> returned, but it may or may not have a relationship to the database. The
> PersistanceState on the object is *always* HOLLOW, regardless of whether
> or not it can be mapped.
>
> I tried modifying the PK attribute in cayenne, but it doesn't affect the
> state of the object.
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienen..laska.net]
> Sent: Friday, August 06, 2004 2:24 PM
> To: Orion Fields
> Cc: cayenne-use..bjectstyle.org
> Subject: Re: Testing for Valid Objects
>
> Orion Fields <ofield..martserv.com> wrote:
> > for the many to single or single to single relationships, how
> > does one go about testing to see if the object exists?
> >
> > What I have is a try catch block around the resolveFault of the object
> > which may or may not exist. I'd rather not catch a
> > cayenneruntimeexception for this. Is there a better way, prefetching
> > aside? (I say prefetching aside b/c the object is nested a few objects
> > down. I tried the read property, ie myobject.readProperty("Artist"),
> but
> > that doesn't returns the same hollow object as myobject.getartist.
>
> For most cases, I'd think you could just check for null.
>
> I know that I do have one case where my restricting qualifer hides the
> object from Cayenne, and I may have dangling database references because
> of
> this.
>
> In that particular case, I resort to using the following:
>
> PaymentMethod aPaymentMethod =
> aPaymentHistoryObject.getPaymentMethod();
>
> // If the fault doesn't resolve, then the payment
> method
> must have been invalidated
> aPaymentMethod.resolveFault();
> if (PersistenceState.TRANSIENT ==
> aPaymentMethod.getPersistenceState())
> {
> aPaymentMethod = null;
> }
>
> I can't think of any other places in my code where I have a
> non-mandatory
> one-to-one relationship that I don't just handle by checking against
> null.
>
> -Mike
This archive was generated by hypermail 2.0.0 : Fri Aug 06 2004 - 14:47:06 EDT