Not at the moment. I figured since it wasn't taken before it would wait until
after 1.0. I have frozen my version of OJB because we're rolling the product
out next week. Sometime after that I was hoping to update OJB again and make
sure the patch still fits in and works well (if I have
hi john,
do you have an up-to-date version of this patch you could post on the list ?
jakob
John wrote:
I figured that would fix it, but I also figured that was in there for a reason
and I didn't want to change something I didn't completely understand. That's
mainly why I asked why it had to
I figured that would fix it, but I also figured that was in there for a reason
and I didn't want to change something I didn't completely understand. That's
mainly why I asked why it had to be that way.
I'm the one that has the patch for deep-prefetching via joins, so I don't
really care,
hi john,
have you tried disabling the collection-desriptor tweaking in
RelationshipPrefetcherImpl#prepareRelationshipSettings() ?
public void prepareRelationshipSettings()
{
setCascadeRetrieve(getObjectReferenceDescriptor().getCascadeRetrieve());
I sensed that, but I'm not sure the penalty for loading an object twice is is
bad as the penalty I was getting. A lot of places in our code assume the
object reference is loaded on a required relationship. One thread was
prefetching and turned off auto-retrieve, then another came in and
hi john,
John wrote:
Has there been any solution to this issue (OJB188)? This bit me in the butt,
but of course it took quite a bit of digging and debugging to realize this is
what was happening. Why exactly is the value changed while prefetching?
auto-retrieve is disabled during
Has there been any solution to this issue (OJB188)? This bit me in the butt,
but of course it took quite a bit of digging and debugging to realize this is
what was happening. Why exactly is the value changed while prefetching?
I have a patched version of OJB that was based on HEAD from the
