Hi, On Fri, May 20, 2011 at 1:27 PM, Peter Rabbitson <[email protected]> wrote: > On Fri, May 20, 2011 at 12:58:09PM +0100, Pedro Melo wrote: >> On Fri, May 20, 2011 at 3:00 AM, Peter Rabbitson <[email protected]> >> wrote: >> > On Fri, May 20, 2011 at 11:52:18AM +1000, Toby Corkindale wrote: >> In the meantime, I reverted the commit like this for my personal use: >> >> https://github.com/melo/dbix-class/commit/ffdb8e2d7e01cc2a8d3b920c43c2d67c6748b988 > > I think you missed the backlog in-channel earlier. I was actually hoping you > guys to take care of it :) > > [19:51:46] <riba> oh ffs > [20:18:12] <riba> http://paste.scsys.co.uk/104045 > [20:18:15] <riba> arcanez: ^^ > [20:18:21] <riba> melo: ^^ > [20:18:37] <riba> please revert this commit, we'll ship a release within a > week > [20:18:59] * riba fucks off
Read the pasta above and its a nice summary but no proposed solution. I can revert your latest commit, is that what you are asking for? >> It would be better for component writers had a hook point that is >> always called. Given that it would be a new hook point we can make >> sure it has the proper signature. It would be called in >> DBIx::Class::ResultSource::_invoke_sqlt_deploy_hook as the last thing >> like this: >> >> my $class = $self->result_class; >> $class->new_name_for_new_sql_deploy_hook($self, @_) if $class; >> >> What do you think? > > I personally do not like this, but mainly because I hate sqlt_deploy_hook > in general - it is not a deploy() hook. It is invoked from within > deployment_statements(), which makes the whole thing even more confusing and > fragile (i.e. if you do have a ddl-dir already, none of your hooks will ever > fire). Furthermore the choice of having the "hooks" live in result classes > is down the same alley as ResultSetManager. I would strongly recommend > discussing with amiri/mst their experience working with ResultSource (note > not Class, Source) componentns, as this is the correct, natural place for > such a hook. Personally I don't mind at all if this "hook" is moved to a more correct place. What I need is a way to tweak the SQL::Translator stuff before it gets deployed or exported to SQL files. The name, where to put it, I'm flexible about that. I used sql_deploy_hook() because that was what I had at the time. I'll try and catch mst/amiri tomorrow and see what they suggest. I would then adjust DBIC and my own DBICx::Indexing to match that. > Note I *am* open to discussion on your earlier proposal, but please understand > that what you are proposing is a last-resort architectural compromise, which > I really would like to avoid. I understand. I don't have a problem waiting for a better solution. In the meantime, I froze a git branch and added it as a submodule on my project to work around it. When this problem is solved I just have to remove the submodule. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:[email protected] mailto:[email protected] _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
