[jifty-devel] Handling register_triggers with mixins on virtual models

[Andrew Sterling Hanenkamp]

On 8/22/07, Jesse Vincent <jesse at bestpractical.com> wrote:
>
>
> On Aug 22, 2007, at 12:50 PM, Andrew Sterling Hanenkamp wrote:
>
> 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.
>
> I can think of a couple good solutions and I'm thinking of implementing
> both:
>
>    1. Virtual models branch change: Add a new register_triggers_late()method that is only called on database-backed models when a column is
>    created after register_triggers() 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.
>
>
> #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?
>

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.

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.

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.

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.


>    1. Trunk change: Add two new "pseudo-triggers" before_any_set and
>    after_any_set. Setting a before_any_set trigger would cause a
>    before_set_X trigger to be set for every column on the table. The
>    after_any_set trigger would do the same for after_set_X. The virtual
>    models branch would then add these triggers to any new column as they are
>    created as well.
>
> I know I like #2.
>
> after_set and before_set feel more natural than after_any_...
>

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.

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070822/d730eb09/attachment.htm