I ran into an interesting issue today. I'm having some trouble testing a database-backed class that uses a mixin, but needs to register triggers for a column that is created after register_triggers() has already been called. Which is pretty much always the case unless you reload Jifty completely after creating all the columns.
<br><br>I can think of a couple good solutions and I&#39;m thinking of implementing both:<br><ol><li><span style="font-weight: bold;">Virtual models branch change: </span>Add a new <span style="font-family: courier new,monospace;">
register_triggers_late()</span> method that is only called on database-backed models when a column is created after <span style="font-family: courier new,monospace;">register_triggers()</span> has been called. It would pass the new column info to the method so it could do any column-specific trigger updates. This would allow a mixin that may need to implement additional triggers on new database-backed columns to do so without mucking with the existing API.
</li><li><span style="font-weight: bold;">Trunk change:</span> Add two new &quot;pseudo-triggers&quot; <span style="font-family: courier new,monospace;">before_any_set</span> and <span style="font-family: courier new,monospace;">
after_any_set</span>. Setting a <span style="font-family: courier new,monospace;">before_any_set</span> trigger would cause a <span style="font-family: courier new,monospace;">before_set_X</span> trigger to be set for every column on the table. The 
<span style="font-family: courier new,monospace;">after_any_set</span> trigger would do the same for <span style="font-family: courier new,monospace;">after_set_X</span>. The virtual models branch would then add these triggers to any new column as they are created as well.
</li></ol>Any objections/suggestions?<br><br>Cheers,<br>Andrew<br>