Thanks for your answer, and thanks for pointing out the problems I could meet recording changes with Storm.
2011/10/27 James Henstridge <[email protected]>: > On Fri, Oct 21, 2011 at 1:25 AM, Vincent Alquier > <[email protected]> wrote: >> First of all, sorry for my approximate english... >> >> For a project I am currently working on, I am trying to migrate from a >> homemade ORM to storm. One of my needs is to get all changes applied >> to an object on flush. The goal is to fill an history table with any >> changes. >> >> Is it safe to call Store._get_changes_map into the __storm_pre_flush__ >> hook ? And then, to save the changes into the __storm_flushed__ hook ? > > The underscore at the start of the _get_changes_map() method indicates > that the method is private, so it would be better to find some other > method to do what you want. I understand this is not recommended at all to use a private method outside its context. What I did is a bit better, but not recommended neither : I did override the _get_changes_map method to notify me of changes. This solution is very vulnerable to changes in Storm. class MyOwnStore(storm.store.Store): [...] def _get_changes_map(self, obj_info, adding=False): changes = super(Store, self)._get_changes_map(obj_info, adding) self.changeManager.notify(obj_info, changes) return changes > > One thing to keep in mind is that it is possible to make changes in > Storm that won't trigger these flush hooks, such as through the > ResultSet.set() method (which generally corresponds to an UPDATE > statement acting on rows that may or may not have Python > representations), so if you require all changes to be recorded, you > might be best off going with database level triggers. Database triggers are massively used in my project, but can't cover my needs on this specific case. > > If you can't use triggers, and are not going to use the bulk update > operations Storm provides, then perhaps the validator feature might > cover your needs? If you attach a validator to a property it will be > called each time there is a change, so you could use that to record > which fields have been changed. I didn't look at the validator feature. Thanks for the tip, it looks promising ! Another point, I am a bit confused with the event mechanism. It looks like it have been thought for internal Storm needs, more than as a user feature. Some examples : - store._event is private but not the obj_info.event. - An event is emitted on "global store flush start", then on any "one flushed". Why not on "one flush start" and on "global store flushed" ? - The __storm_flushed__ hook looks redundant with the "flushed" event. -- Vincent Alquier [email protected] -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
