Just to be more precise: On Fri, Oct 9, 2009 at 6:40 AM, Zbigniew Lukasiak <zzb...@gmail.com> wrote: > On Fri, Oct 9, 2009 at 6:25 AM, Peter Rabbitson <rabbit+d...@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/ _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk