cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <blackn...@gmail.com>
Subject Re: Read-only contexts?
Date Fri, 05 May 2017 11:04:42 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message