#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 <[email protected]> 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 <[email protected]> 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 >> >> >
