cayenne-user mailing list archives

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


On Fri, May 5, 2017 at 7:04 AM, Michael Gentry <> 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 <> 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

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