Fwd: [Dbix-class] Breakage on .127 -> .192 upgrade

[Pedro Melo]

Hi,

On Fri, May 20, 2011 at 1:27 PM, Peter Rabbitson <rabbit+dbic at rabbit.us> 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 <rabbit+dbic at rabbit.us> 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:melo at simplicidade.org
mailto:melo at simplicidade.org