Hi, On Fri, May 20, 2011 at 1:27 PM, Peter Rabbitson <rabbit+d...@rabbit.us> wrote: > > 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
See https://github.com/melo/dbix-class/tree/people%2Fmelo%2Frevert-sql-deploy-fixes Basically branch people/melo/revert-sql-deploy-fixes. It reverts the commit in question and adds a new test to make sure sql_deploy_hooks() is still called on components. I'll try and get perms to push this to the main git repo. > 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. I'll do so and suggest an alternative. I agree that result_class is the wrong place for this, but it was the one we had in the previous version. My branch above returns the code to the previous status quo until this is solved in a more clean way. > 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 also don't like it, because I agree that putting this on the result class is the wrong place. I'll talk with mst about his experience and propose something. In the meantime I would like you to accept the tree above to go back to the previous extensible design. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:m...@simplicidade.org mailto:m...@simplicidade.org _______________________________________________ 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/dbix-class@lists.scsys.co.uk
