Andrus Adamchik <andru..bjectstyle.org> wrote:
> A better test would be to do DataRowStore.forgetSnapshot(...) directly,
> as it will emulate what happens on overflow, and won't have side
> effects on the tested ObjectStore and DataContext.
I've added tests for this, and sure enough, they fail.
I left in the invalidateObject tests and added both sets of tests for update
as well (which all work).
So I guess this means that manually invalidating is safe (although I can't
see the use case) and the only brokenness of the implementation right now is
cache overflow between the time the object is deleted and the changes are
committed.
I also cleaned up the naming of the tests to clearly indicate whether
they're expected to succeed or fail, and I added a simple success case for
updates.
What side effects are you referring to? Not sure what difference it would
make considering the test ends after the commit.
-Mike
> On Mar 3, 2005, at 11:05 AM, Mike Kienenberger wrote:
>
> > Andrus Adamchik <andru..bjectstyle.org> wrote:
> >> what if there is no cached snapshot either (e.g. some snapshots are
> > invalidated manually or removed when a shared cache reaches its size
> > limit)?
> > One solution I see is to retain snapshots of deleted objects (just
> > like we
> > do for the modified ones) if optimistic locking is involved.
> >
> >
> > Andrus, I tried creating failing unit tests by invalidating manually
> > the
> > object to be deleted, but both of these situations work.
> >
> > context.invalidateObjects(Collections.singletonList(object));
> > context.deleteObject(object);
> > context.commitChanges();
> >
> > context.deleteObject(object);
> > context.invalidateObjects(Collections.singletonList(object));
> > context.commitChanges();
> >
> > Is there any point in committing these tests?
> >
> > -Mike
> >
>
This archive was generated by hypermail 2.0.0 : Fri Mar 04 2005 - 08:01:30 EST