Further enhancements for maglev_persistable(true) #289

merged 19 commits into from Apr 3, 2013

4 participants


During a call to klass.maglev_persistable(true), we now copy included modules in the persistent namespace and copy class methods into their respective persistent method dictionary as well.

Furthermore, it adds the maglev_persistence tests to the .travis.yml: they missed before.
Is this a good idea?

MagLev Engineering Team member

I'm still thinking about whether this needs to be more flexible. Like, is it a use case that I want to persist the methods defined on a class, but not the inherited methods? Or maybe I want to persist only methods that are in the direct inheritance chain, but not the ones in included modules? I think we should at least add something to the persistence documentation about this. Maybe @srbaker or @snarfmason also have some opinions on that.


We discussed this a fair bit with Peter MacLain while we were in the Portland office in February. This one's pretty tricky, I'm not really sure what the right answer is.

I'm inclined towards flexibility, but the question I think really needs an answer is: What happens when we change a method definition? I have a class C that inherits from parent class P and includes module M. I have a bunch of instances of C in the persistent root. What happens if I want to add a method to C,P or M? What happens if I change one? And I think most difficult, what happens if I delete one?

I'm thinking uses cases like "don't persist inherited or included methods" might be useful for answering those question. But I'm not totally sure.

@knub knub merged commit 4f1306a into master-1.9 Apr 3, 2013

1 check passed

Details default The Travis build passed
@knub knub deleted the stefan/maglev_persistable-persists-modules branch Apr 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment