On Nov 10, 2006, at 8:53 AM, qvx wrote:
>
> I have an ActiveMapper class which looks like this:
>
> class OraJob(ActiveMapper):
> class mapping:
> id = column(Integer, primary_key = True)
> job_type = column(Unicode(30))
> source_type = column(Unicode(30))
> ...
>
> Attributes are used / should be used in readonly manner. All
> updates to
> database are happening via specialized Oracle procedures (that in turn
> use AUTONOMOUS_TRANSACTION). This is so because changes to this object
> must be committed to database no mater what is the outcome of main
> transaction and must be written immediately so I can track the
> progress
> of job from outside.
>
if you have an object that is to be saved in a distinct transaction
all its own, it should be used in a distinct Session separate from
the one servicing the main transaction. its exists within its own
unit of work.
> How can I go about solving this problem:
> 1. somehow make attributes readonly for outside world but let me
> change
> attributes from inside customized update function without affecting
> dirty state
>
readonly attributes can be implemented like this:
class MyClass(object):
myattribute = property(lambda self:self._myattribute)
mapper(MyClass, mytable, properties={
_myattribute:mytable.c.myattribute
}
)
no, you cant do this with ActiveMapper. this is one of the 8
bazillion reasons the data mapper pattern is better than active record.
> 2. expunge object from session inside __init__ (if it is possible at
> all)
if youre not using ActiveMapper, then you also wont by default have
the "magical" in-session behavior (note that the __init__ into
session behavior is provided by SessionContextExt which is
independent of ActiveMapper).
> 4. create object somehow so it doesn't end up inside session (is it
> enough to say _sa_session=None when creating object)
that might work too, if you are using ActiveMapper and or
SessionContextExt.
> It seems that "readonly" attribute would be the best solution, because
> the only interface for changing job state is through several well
> defined functions (start/update/finish/fail)
the method above can implement "readonly". this feature does not
belong in SA directly since it has nothing to do with mapping classes
to tables and everything to do with an application-specific class
behavior.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
