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 14:07:15 GMT
Hi Alexander,

Those are also good suggestions for implementing this feature.

Thanks,

mrg


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

> 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
> > >>
> > >>
> > >
> >
>

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