I implemented a very crude flush/commit-time version of this today
that disables all modifications. Michael suggested the use of
connection_callable to provide fine-grained control of which engine to
use for modifications. I haven't gone through all the details yet but
it seems to work for my basic tests.
pjjH
class ReadOnlySession(DefaultSession):
def __init__(self, **kwargs):
super(ReadOnlySession, self).__init__(**kwargs)
self._mapper_flush_opts = {'connection_callable',
self._disable_any_modifications}
def _disable_any_modifications(self, mapper=None, instance=None,
**kwargs):
return None
On Aug 24, 1:28 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote:
> Martijn Faassen wrote:
>
> > Hi there,
>
> > I'm investigating ways to make an ORM-mapped instance read-only,
> > dependent the value of a particular attribute (database backed or not).
> > If an object has a certain state, I want to prevent normal users from
> > making a modification. Other objects connected to the same session
> > should be editable however.
>
> > I've tried to figure out various possibilities, but none of them seem
> > entirely satisfactory:
>
> > * I could use AttributeExtension that checks the 'readonly' attribute
> > and if so, raises an exception when modification is attempted. As far as
> > I can see I'd need to manually define an AttributeExtension for *all*
> > attributes, and I'd just like to do this once per mapped class at most.
>
> > * It may be possible to use MapperExtension and modify before_update
> > somehow. This is a bit late however - I'd prefer an exception to be
> > raised as soon as someone tries to modify an attribute.
>
> > * I could proxy the whole instance with a security proxy, along the
> > lines of zope.security, which could then do the checks. I'd like to
> > avoid security proxies if I can get away with it however. I'd prefer it
> > if the objects that came back from session.query() were already
> > configured to do read-only checks.
>
> > * I could try to use some form of row-level security on the database
> > level. MySQL, the database I'm working with, doesn't have such feature
> > as far as I'm aware, however. Also this'd be warning the developer a bit
> > late - I'd prefer if it happened directly when modifying the attribute.
>
> > Does anyone have any clues as to what a good implementation strategy
> > would be?
>
> did you try implementing __getattribute__() ?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
