ARGH. Rework how we instrument code #11

caryfitzhugh opened this Issue Apr 13, 2012 · 5 comments


None yet

3 participants


What we have is cool - and we should keep it (enable a class, and any subclasses of it to be instrumented).

But we also need to be able to traverse a set of files, load them in, instrument any module or class inside them, and then attach the 'if anything extends/includes/subclasses this, wrap the methods' to it.

Since, we are getting to the question of 'what constitutes a view', or a controller, or a model?

I'm not sure yet. :P

Controllers are easy, and so are views.

Models are trickier - and they need different handling, because you may have a model which is not an activerecord, and does not subclass active record... so we wouldn't catch it right now. You may also have a module in lib which you call from a controller - that too would not be caught right now, because it does not subclass from one of our initial classes.

So - we need to traverse some directories, load in the files - see what classes are defined, and then add our definitions to them. (Wonder if it will work with development mode reloading!!?)


This is what newrelic does -- kindof what we are doing, in a round-about way (and they need special adapters for things like acts_as_solr, and etc. etc) -- so we may have an advantage over them if I can get this working...



Same as DatabaseCleaner? ActiveRecord, DataMapper, Sequel, MongoMapper, Mongoid, and CouchPotato?

Maybe test like them too? e.g.,


Looks like I may be able to use Ripper, to rip the class and module definitions from a given file -
then load them - and apply the extensions/inclusions to wrap their methods (and subsequently added methods).


I think that is a great list, but we should really just nail active record for now, then mongo -- so we can use it on ziplist and truestack's apps out the box.


I think mongomapper and activerecord are what we'll use.
Need to implement the ability to 'tag for tracking' a module -- so when it's included we can piggy back.
Then we can do things like, when a new type of adapter comes out we just say:

TruestackRails::Instrument.instrument_methods!( ClassOrModuleOfThirdPartyGem, 'type / controller / model')

And it'll either extend the class or module...

A bit tricky if the module is tagged as 'model', but it is included in a 'controller'... but I guess that's just 'crazy talk'


Was not as bad as I thought -- just assume that everything is a model method - and refine from there.

So I extend Class with my wrappers, and it will wrap anything defined in the code paths with these methods.

Had to do a bit of jumping to get module's self. methods working - but they do now (hardcoded to model though).

Regardless, I think this is done! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment