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 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/ _______________________________________________ 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