On 8/22/07, <b class="gmail_sendername">Jesse Vincent</b> <<a href="mailto:jesse@bestpractical.com">jesse@bestpractical.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">
<br><div><span class="q"><div>On Aug 22, 2007, at 12:50 PM, Andrew Sterling Hanenkamp wrote:</div><br><blockquote type="cite">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'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></ol></blockquote><div><br></div></span><div>#1, I'm not 100% sure I understand. is "late" the right name for it? is it about registerning new triggers or refreshing the registered triggers?</div></div>
</div></blockquote><div><br>I have no idea if that's the right name, but it's what came to mind first. This is the easier of the two to implement, though. I just need to add some tests and I'll have a pair of patches for Jifty::DBI and virtual-models. My thought would be that register_triggers_late() (or whatever name it ends up with) would be called by add_column_in_db() for each column added (or beside the call to add_column_in_db()). Similarly, delete_column_in_db() will delete any triggers associated with a column in case it's deleted and then re-added.
<br><br>Does that make it more clear? I'll include the patches next if you're still unclear. I want to make sure it works first and my day has been kind of twisted around today so I haven't had a chance to finish what I started this morning.
<br><br>A similar possible solution would be to have a register_triggers_for_column() method that is called for each column in the table immediately after register_triggers() is called and then again whenever a new column is added.
<br><br>I haven't yet considered the case of a column rename, but that could be handled as if by a delete + add of a column as far as the triggers are handled.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><span class="q"><blockquote type="cite"><ol><li><span style="font-weight: bold;">Trunk change:</span> Add two new "pseudo-triggers" <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></blockquote></span><div>I know I like #2. </div><div><br></div><div>after_set and before_set feel more natural than after_any_...
</div></div></div></blockquote><div><br>I am not sure where the best place is to implement this one. It seems like it should be an override of add_trigger() in Jifty::DBI::Record, but since add_trigger() is directly imported into Jifty::DBI::Record from Jifty::DBI::Class::Trigger, that's a bit messy. I can do the messy solution, but if there's a better way, I'd rather do that instead if someone has a suggestion.
<br><br>Cheers,<br>Andrew<br></div></div><br>