Tracking down model calls

Hi,

Have been having a re-occurring issue with some of the apps I have built. Sometimes I am updating a sites functionality when I find myself having to modify a model. This means tracking down everywhere that model is called.

Does anyone have any tips about how this can be, or should be handled, more efficiently or properly.

Just to note this is not when I can simply add a similar function to the one being modified, but need to modify an existing function. Specifically when I need to modify the terms used in the model function.

Any advice or tips about how to avoid this or do this more efficiently would be warmly welcomed.

Thank you in advance,

Paul.

I usually just use the IDE and do a mass search of all files in the /application dir for "->model_name->". I leave of the "$this" because in libraries and some other places it's used differently using an instance of the CI object, so leaving it off will find everywhere it's used.

I usually just use the IDE and do a mass search of all files in the /application dir for "->model_name->". I leave of the "$this" because in libraries and some other places it's used differently using an instance of the CI object, so leaving it off will find everywhere it's used.

Thanks for that. 

You know I have suspected for a while that my editor has been slowing me down. I think I am going to investigate some other options right now.

Thanks again,

Paul.

As CroNiX mentioned, I usually just use the search/find features of my editor to track them down, and I usually just search for the model name in all lowercase (or case-insensitively), without bothering with the -> or $this. If my model's class name isn't unique for some reason, this process would just serve as a reminder for why that's important, and context will tell me whether the found result is relevant.

Further, though, I would work on figuring out why you need to do this in the first place. In general, you should avoid modifying an existing model in a way which would require you to update all (or multiple) uses of the model or a given method in the model. For example, if I need to add an argument to a method for some reason, I add it to the end of the argument list with a default value which gives me the existing behavior, so I only need to modify the call to the model's method in the case(s) where the new behavior (and associated parameter) is necessary.

The primary reason I end up searching for all calls to an existing method is when I rename a method. In that case, I deprecate the existing method and turn it into an alias for the new method, so my existing calls still work until I have a chance to change them. I usually mark deprecated methods with a comment including the version or date of the deprecation, so the information is readily available when I run across the method later. In my application, I usually try to commit the deprecation of the method and the changes to other parts of the code to use the new method as separate commits, in case something goes wrong in changing the other files. When I come back to the model in the future, if the deprecated method is old enough, I can search for uses of the method to determine whether it is safe to remove it.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

@mwhitney

Thank you for that reply. Your suggested usage of alias is a great idea and I will definitely be using that in the future. In fact after a quick google of the topic I couldn't believe i had overlooked that.

As for the why the model is changing, in this particular case, the site is nearly complete when lo and behold a request comes in for a functionality change, that completely alters the method I was using to achieve the initial goal. In this case it is a call handler that was intended for outbound calls only, and now has to cater for inbound calls too. In an attempt to not rewrite everything but adapt the system I had coded, I found myself having to rewrite the bit that initiates the call and change the model.

In previous cases it has always been the extension of functionality. Actually more accurately the changing of functionality, not just extending. I usually get away with adding on additional variables to the models, but not always. Hence the back tracking of model calls.

I did once try, every time I wrote a model call, updating the model comments. But that very quickly became impossible to maintain accurately. And mostly a waste of time too.

I have since discovered my editor does have a 'search all files' facility for local files but can't search the live site directories (not surprisingly). However have now downloaded the entire application folder and searched that and tracked down only five instances of the model call which are easy enough to fix now.

I love the alias idea though and will definitely be using that from now on where I can. Makes so much sense for code that is currently working but needs extending.

Thank you again,

Best wishes,

Paul.