Uggh. After a little bit of debugging hell, I found that the caching
is in fact behaving properly... which of course, Andrus knew already.
Basically, I was not updating the cache on a dependent query root,
causing the object graph to have a hole in it and therefore filter the
result out. Invalidating both roots took care of the problem.
On 2/13/06, Cris Daniluk <cris.danilu..mail.com> wrote:
> I wrote a test that basically mimics my behavior, using
> CayenneTestCase as a base... and I can't reproduce the behavior
> either.
>
> So, I'll be suffering through the debugger if anyone needs me :)
>
> On 2/13/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > The test case that has conditions similar to CAY-444 is
> > DataContextNamedQueryCachingTst
> >
> > I just added extra code to insert a new row in DB before refresh -
> > same story, it works. So I am stuck in my attempts to reproduce it.
> > Debugging cache interceptor methods on your end is probably the only
> > way to figure it out now.
> >
> > Andrus
> >
> >
> > On Feb 13, 2006, at 11:34 AM, Cris Daniluk wrote:
> >
> > > On 2/13/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > >> The only difference I see compared to Cayenne test cases is that
> > >> "refreshingObjects" set to "false". So I flipped that flag in the
> > >> test DataMap and re-ran the tests, and it still works. Very strange.
> > >>
> > > Well, typically I would pass false. This is my example of refreshing
> > > the query. The SQL executed returns 259 rows, the correct amount. Any
> > > changes in existing records are updated successfully. Only newly added
> > > records are not viewed (in my test case, I still see 258 records if I
> > > were to re-execute performQuery(queryName, false);
> > >
> > > I took a quick look at the tests in DataContextQueryCachingTst and I
> > > don't think this is asserting quite the same thing..
> > >
> > > Cris
> > >
> >
> >
>
This archive was generated by hypermail 2.0.0 : Mon Feb 13 2006 - 15:13:33 EST