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

[Peter Rabbitson]

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.

> 
> 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.

> 
> 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.


This is of course just my one-sided take on the issue, I am not a heavy
S::L user (deploy ftw).

Cheers