[Dbix-class] Re: Backcompat tests for the dev version of DBIx::Class::Schema::Loader

[Zbigniew Lukasiak]

On Fri, Oct 9, 2009 at 6:25 AM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> On Thu, Oct 08, 2009 at 05:55:04PM +0200, Zbigniew Lukasiak wrote:
>> Hi,
>>
>> I am now trying again to make it work and I am really sorry but even
>> after all those IRC discussions I am still a bit puzzled about how the
>> backcompat layer is supposed to work.  So once again - I understand
>> that the scenario is like that:
>>
>> I have an old schema
>> I use the new Loader to load a new one
>> the backcompat reads the old schema and notices that it is old and it
>> switches itself on
>> the loaded schema is compatible with the old one
>> then I call dump_to_dir - and it is dumped
>> the old schema is overwritten with the new one (but compatible)
>>
>> Is that what you have in mind?
>>
>> If the answer is yes - then there are two questions
>>
>> 1. Should there be any changes between the old schema and the new one?
>>  If there are any then how to decide what changes are compatible and
>> what are not.  And if there should not be any change - then what is
>> the purpose of overwriting one schema with an identical one?  Wouldn't
>> it be simpler to just refuse overwriting old schemas?
>
> You are mixing two issues here. The first is updates of non-changed
> resultsources - this is something that needs fixing, and acmoore was
> about to do something about it (not sure how far he went).
>
> The second problem is backwards compatibility - the whole issue centers
> around relationship naming. They are purely cosmetic, but changed between
> the old and new codebase. So without changing your actual database, your
> code doing artist->cd would all of a sudden stop working, as the rel is
> now called 'cds'. This is what we need to guard against.

OK - so the question here is what other changes there are?

I am not mixing those two things without purpose - leaving the old
schema intact is just a very simple solution to backwards
compatibility :)  And if there isn't anything changed - then it would
be enough.  So once again are there any changes that are not nullified
by the backcompat layer?

>> 2. If we are overwriting with the compatibility adjustments - then we
>> need to mark the new schema somehow, so that subsequent re-dumping
>> will leave these adjustments.
>
> This is correct and afaik has not yet been discussed. Once the user wrote
> code against ->cd it needs to kep working, unless the user decides to
> break things.

OK

>
>>
>> Initially I imagined that the backcompat is needed for dynamic
>> loading, then there is no old schema, so I was not thinking about
>> these problems, but in the IRC conversations someone said that dynamic
>> loading is not important.
>>
>
> It was me, and I didn't say that :) Dynamic loading can not possibly
> know what S::L was used on prior invocation, thus it is impossible to
> detect when back compat is needed. My take on this problem was:
>
> dynamic S::L is *RETARDED*. It needs to die in the following manner:
>
> 1) A warning (which can be disabled of course) is issued when S::L
> is used dynamically, stating that this is dumb, and you get to kep
> the pieces when it stops working.
> 2) When S::L is used dynamically we *always* use backcompat mode.
> Want to reap the benefits of the new relationship naming? - use on-disk
> files.

OK

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/