On Feb 12, 2009, at 07:48, Russell Keith-Magee wrote: > On Thu, Feb 12, 2009 at 2:54 PM, Ludvig Ericson > <ludvig.eric...@gmail.com> wrote: >> >> I fail to see how "it has consequences for existing code", as Russell >> put it. > > It has consequences because you are proposing to change the order in > which indexes and custom SQL are applied. Any code that depends on the > existing order will be affected.
Just want to note that *I'm* not proposing any changes. >> I did discuss this with Bergström, and we came to the conclusion that >> it won't actually break much code, if any. > > If it has the potential to break _any_ code, it is an unacceptable > change. The Django core developers have stated that we will maintain > backwards compatibility of the v1.0 interface, so any change with even > the _potential_ to affect backwards compatibility will need to be > checked very carefully. > > However, the larger point is that you don't get to make that decision > about whether a change is acceptable or not. You can discuss a change > and make a recommendation, but ultimately the decision needs to be > made by a core developer. The Design Decision Required triage state > exists for exactly this reason. I don't think it's "the larger point." I misunderstood the triaging system, and incorrectly changed it. Bennett reverted. I apologized. End of that. What I meant by "ready for checking" was that the patch applies cleanly, runs, and does what it is intended to do. And obviously that was mistake, and again: I realize this now. >> The only case which it could break, AFAICT, is if custom SQL manages >> to depend on the absence of indexes. I guess that could break code >> that violates indexing constraints, which are applied later, maybe? I >> don't know. > > This is what needs to be confirmed, and given that it is a non-trivial > change, your decision needs to be confirmed by a core developer. I am > willing to be convinced, but you will need to prove to me that there > is no backwards compatibility problem here. The discussion in this > thread so far hasn't done that. I realize that my opinions and decisions play a very small role in the development of Django, but I try to express them so that core developers may read them, and either think "what a retard", or "fair point." I guess the question really is: is this custom SQL execution order change really the right fix for the issue? I can't say I'm convinced that it is, given your next paragraph. I would suggest the need for signaling that a custom SQL file should execute post-indices. One solution, which is entirely backwards-compatible, would be to say that "if you want your custom SQL to run after indices creation, name files '*.post.sql,'" or something like that. That has its own issues, but you get the general idea. > To answer the original question (why is it done in this order) - > mostly historical reasons. Originally, Django didn't have fixtures, so > initial data were all loaded from initial SQL. It's generally faster > to insert data and then add indicies, hence the order. When Django > added fixtures, the order wasn't changed. I see, so the custom SQL machinery grew out of being a crude version of fixtures then. I think the cause of confusion here is that Bergström and I both were expecting it to be for more than loading data -- I want to create a view in it (hence my interest), and he wants to drop some excessive indices. After pondering some more, I realized the docs actually say "initial SQL data", and so I'm not sure if this change is actually a good idea or not. - Ludvig --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
