Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
MIME-Version: 1.0
From: Lon Varscsak <lon.varscsak@gmail.com>
Date: Wed, 16 Nov 2016 15:41:12 -0700
Message-ID: <CALAw18z5yk5PqjHazov3w5rR+wu54O=2dnufugJnR56QWFO0oA@mail.gmail.com>
Subject: Shared Cache and relationships
To: Apache Cayenne <user@cayenne.apache.org>
Content-Type: multipart/alternative; boundary=001a114e52f023ffc5054172c52d
archived-at: Wed, 16 Nov 2016 22:41:18 -0000

--001a114e52f023ffc5054172c52d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So previously this year, I posted about about how while fetching an object
that it=E2=80=99s relationships weren=E2=80=99t automatically refreshing, e=
ven though I was
not caching (myself) any data.  This is where I learned about =E2=80=9Cshar=
ed
caches=E2=80=9D and realized that if I turned it off, I kind of get the beh=
avior I
want (except now peer synchronization doesn=E2=80=99t work).  Data within a=
 single
context is cached (if I choose), but once the context is gone, the
snapshots are gone.  It doesn=E2=80=99t seem to make sense that a global ca=
che
would hold onto snapshots beyond the life of the objects across
contexts=E2=80=A6but that=E2=80=99s what it appears to do.

The response was, =E2=80=9Crefresh your relationships with prefetches=E2=80=
=9D.  This
doesn=E2=80=99t seem like a clean solution to me.  It forces the developer =
to =E2=80=9Cbe
aware=E2=80=9D of stale data and force fetches on relationships that they m=
ight not
need in that moment.  Realize that a lot of components in my application
might shared data (like a Customer, or an Order), but the components don=E2=
=80=99t
necessarily access all of the information in those relationships.  I
believe EOF, the snapshot would decrement to 0 (when that snapshot wasn=E2=
=80=99t
referred to anymore by any context) and the next fetch would be fresh.  Is
there no concept like this for Cayenne?

Any help would be appreciated.  It=E2=80=99s very possible I=E2=80=99m just=
 missing the
obvious approach.

-Lon

--001a114e52f023ffc5054172c52d--