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

[Zbigniew Lukasiak]

Just to be more precise:

On Fri, Oct 9, 2009 at 6:40 AM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> 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 know there are some changes, like the auto_increment flag that I
need, that are not likely to be covered by the backcompat layer.  Now
the question is how to separate those two kinds of changes - how do
you decide what change is compatible and what is not.
On the extreme interpretation adding a new flag to an existing field
will change it's behaviour - so it is not totally back compatible.

I hope that clarifies what I am talking about - and sorry if that was
already covered somewhere, I must have missed it.


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