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

[Peter Rabbitson]

On Fri, Oct 09, 2009 at 06:52:32AM +0200, Zbigniew Lukasiak wrote:
> 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.
> 

I might be completely in the wrong here, but afaik the backcompat layer
only deals with the relationship naming. The detection of autoinc and
stuff happens in the core, which is shared by both the new and old class
generators. However I could be talking out of my ass, you need to confirm
this with someone who actually dug in the code.

Cheers