Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
MIME-Version: 1.0
Message-ID: <pony-5fc56de2e301e0040eebdead2758ab1b532b4e5a-2cdd7c5c664b49afcd5c6d2a0a72bc8e3eabf814@user.cayenne.apache.org>
Subject: Re: Read-only contexts?
References: <CAOy5kzMQ6XTKn9om2Asb-KH9jryM=JctsV7rBP0TGF0adRy6ZA@mail.gmail.com> <pony-5fc56de2e301e0040eebdead2758ab1b532b4e5a-9202edf48fcd9ca63ace510396a4a8b03dd4378b@user.cayenne.apache.org>
 <CAOy5kzO7+ZgCM2X9tXp=gOPBeZDLWSb9feRjG+19O+d9_iMuwQ@mail.gmail.com>
From: "Alexander"<lex.frei@gmail.com>
In-Reply-To: <CAOy5kzMQ6XTKn9om2Asb-KH9jryM=JctsV7rBP0TGF0adRy6ZA@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 05 May 2017 13:19:21 -0000
To: <user@cayenne.apache.org>
archived-at: Fri, 05 May 2017 13:19:27 -0000

Hi,

thank you and Maik for answering so fast. You saved me a lot of time searching around for nothing.

Your suggestion seems to be the right approach. 
I’d consider making the read-only flag in the ObjectContext final, as to prevent unintended changes. Therefore it has to be set in the ObjectContext’s constructor.

A fail fast behavior should be considered for nested ObjectContexts, i.e. commitChangesToParent() should check the parent’s read-only flag, unless the nested context’s read-only flag is copied from the parent on instantiation (in this case ObjectContextFactory class has to be changed too)..

Let’s hope this feature will be added before 4.0 final.

For now subclassing is a good option.

Thanks again
Alexander


On 2017-05-05 13:08 (+0200), Michael Gentry <blacknext@gmail.com> wrote: 
> #2 should've read:
> 
> 2. Alter CayenneDataObject to check the entity's read-only status AND the
> context's read-only status.  (Change writeProperty(), etc.)  If either is
> read-only and you are trying to sneak a change in, throw an exception.
> 
> mrg
> 
> 
> On Fri, May 5, 2017 at 7:04 AM, Michael Gentry <blacknext@gmail.com> wrote:
> 
> > Hi Alexander,
> >
> > I don't believe what you are asking for is currently doable, even in the
> > latest 4.0 milestone release.
> >
> > An ObjectContext doesn't know anything about read-only.  You can make a
> > Cayenne object read-only in Cayenne Modeler, however this just omits
> > setter-type methods.  CayenneDataObject, which all Cayenne database objects
> > inherit from, doesn't actually restrict setting values if you flag it as
> > read-only in the modeler.  You can directly call writeProperty(),
> > writePropertyDirectly(), removeToManyTarget(), etc on the objects.
> >
> > I think this feature would be fairly easy to add (the information is
> > already in the model's XML files [1]), so perhaps it could be added before
> > 4.0 final.
> >
> > I'd suggest:
> >
> > 1. Add a read-only flag to DataContext and friends.  If you call
> > commitChanges() on a read-only context, throw an exception.
> > 2. Alter each CayenneDataObject which modifies data (writeProperty(), etc)
> > to check the entity's read-only status AND the context's read-only status.
> > If either is read-only and you are trying to sneak a change in, throw an
> > exception.
> >
> > Does this sound like the right approach (to you and other Cayenne users)?
> >
> > As to your localObject() question, I think it should adhere to the 1/2
> > semantics I just mentioned.
> > Thanks,
> >
> > mrg
> >
> > [1] <obj-entity name="..." className="..." readOnly="true"
> > dbEntityName="..." superClassName="...">
> >
> >
> >
> > On Fri, May 5, 2017 at 6:29 AM, Alexander <lex.frei@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I searched for a while, but wasn’t able to find a solution to make an
> >> ObjectContext “read-only”.
> >> Maybe I'm missing something.
> >>
> >> The point is:
> >> As suggested many times, there are situations where it makes sense to
> >> have a shared read-only ObjectContext and other ObjectContexts to commit
> >> changes.
> >> I can certainly handle two and more ObjectContexts, but I need to lock
> >> out other users / applications which can somehow gain access to persistent
> >> objects instantiated through the assumed read-only shared context, since
> >> any application that has access to such objects (maybe obtained from a
> >> service class that is expected to return read-only objects) could simply
> >> call object.getObjectContext().commitChanges(). By the way, this would
> >> also commit unwanted temporary changes that happen elsewhere in the main
> >> application or in the service class.
> >>
> >> Is there a method like CONTEXT.makeReadOnly() to make sure that any
> >> objects that resides in this specific ObjectContext cannot be changed?
> >> Even better, is there a way to let persistent objects, that are bound to
> >> a read-only context, throw an exception?
> >>
> >> Should this be possible, there is only one question left: would it still
> >> be possible to transfer objects retrieved through a read-only
> >> ObjectContext  to a read-write ObjectContext, by calling
> >> localObject(readWriteContext)?
> >>
> >> Any help would be greatly appreciated.
> >> Alexander
> >>
> >>
> >
>