Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
MIME-Version: 1.0
In-Reply-To: <pony-5fc56de2e301e0040eebdead2758ab1b532b4e5a-9202edf48fcd9ca63ace510396a4a8b03dd4378b@user.cayenne.apache.org>
References: <pony-5fc56de2e301e0040eebdead2758ab1b532b4e5a-9202edf48fcd9ca63ace510396a4a8b03dd4378b@user.cayenne.apache.org>
From: Michael Gentry <blacknext@gmail.com>
Date: Fri, 5 May 2017 07:04:42 -0400
Message-ID: <CAOy5kzO7+ZgCM2X9tXp=gOPBeZDLWSb9feRjG+19O+d9_iMuwQ@mail.gmail.com>
Subject: Re: Read-only contexts?
To: Cayenne Users <user@cayenne.apache.org>
Content-Type: multipart/alternative; boundary=f403045f8af216b18b054ec4dd5c
archived-at: Fri, 05 May 2017 11:05:25 -0000

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

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=3D"..." className=3D"..." readOnly=3D"true"
dbEntityName=3D"..." superClassName=3D"...">


On Fri, May 5, 2017 at 6:29 AM, Alexander <lex.frei@gmail.com> wrote:

> Hi,
>
> I searched for a while, but wasn=E2=80=99t able to find a solution to mak=
e an
> ObjectContext =E2=80=9Cread-only=E2=80=9D.
> Maybe I'm missing something.
>
> The point is:
> As suggested many times, there are situations where it makes sense to hav=
e
> a shared read-only ObjectContext and other ObjectContexts to commit chang=
es.
> I can certainly handle two and more ObjectContexts, but I need to lock ou=
t
> 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
>
>

--f403045f8af216b18b054ec4dd5c--