Re: Schema Alteration update
On Fri, Oct 12, 2012 at 4:00 AM, Andrew Godwin wrote: > especially if it's something highly custom internal to a company where you > don't have the time or team to do that stuff properly. > Thank you for highlighting this scenario. Unfortunately, this is usually the case with my one-man projects, and I feel Django needs to take these use cases into consideration more often. Cheers, AT -- 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.
Re: Schema Alteration update
I certainly don't want to tread on anyone's toes - the idea will be that, like in South currently, migrations will be enabled/disabled on a per-app basis, so if you don't want them they won't muck stuff up. Alternatively, we could let the other apps override syncdb. I'm hoping, in fact, that adding the database backends into core will make anyone else who is doing custom migration stuff's lives easier - especially if it's something highly custom internal to a company where you don't have the time or team to do that stuff properly. Andrew On Thu, Oct 11, 2012 at 11:21 AM, Luke Plant wrote: > On 28/09/12 08:41, Andrew Godwin wrote: > > Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps > > not loudly enough - Jacob and I had a talk at DjangoCon EU where he said > > he wanted it all in core, and I tend to agree. > > > > Preston has had a look at what I'm doing/planning with AppCache and > > apparently it'll be compatable with what's in app-loading with a little > > work, which is reassuring. > > > > Only remaining question is whether migration-runner (the smarts) should > > be in contrib or core. I know Alex believes core; I'm split, seeing as > > some people will want to turn it off (so contrib), but it overrides core > > commands like syncdb (so core would be cleaner). > > I'm very happy with South being in core/contrib, but I am aware of other > people who use different solutions. It would be nice if we didn't make > life hard for them. I don't know what that means in practice, but if we > got feedback from the developers of those other solutions it would be > good. We might need something like a 'syncdb --ignore-migrations' option. > > Luke > > > -- > "Because Your lovingkindness is better than life, > My lips shall praise You." (Ps 63:3) > > Luke Plant || http://lukeplant.me.uk/ > > -- > 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. > > -- 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.
Re: Schema Alteration update
On 28/09/12 08:41, Andrew Godwin wrote: > Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps > not loudly enough - Jacob and I had a talk at DjangoCon EU where he said > he wanted it all in core, and I tend to agree. > > Preston has had a look at what I'm doing/planning with AppCache and > apparently it'll be compatable with what's in app-loading with a little > work, which is reassuring. > > Only remaining question is whether migration-runner (the smarts) should > be in contrib or core. I know Alex believes core; I'm split, seeing as > some people will want to turn it off (so contrib), but it overrides core > commands like syncdb (so core would be cleaner). I'm very happy with South being in core/contrib, but I am aware of other people who use different solutions. It would be nice if we didn't make life hard for them. I don't know what that means in practice, but if we got feedback from the developers of those other solutions it would be good. We might need something like a 'syncdb --ignore-migrations' option. Luke -- "Because Your lovingkindness is better than life, My lips shall praise You." (Ps 63:3) Luke Plant || http://lukeplant.me.uk/ -- 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.
Re: Schema Alteration update
Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps not loudly enough - Jacob and I had a talk at DjangoCon EU where he said he wanted it all in core, and I tend to agree. Preston has had a look at what I'm doing/planning with AppCache and apparently it'll be compatable with what's in app-loading with a little work, which is reassuring. Only remaining question is whether migration-runner (the smarts) should be in contrib or core. I know Alex believes core; I'm split, seeing as some people will want to turn it off (so contrib), but it overrides core commands like syncdb (so core would be cleaner). Andrew On Fri, Sep 28, 2012 at 3:22 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Fri, Sep 28, 2012 at 8:29 AM, Jacob Kaplan-Moss > wrote: > > On Fri, Sep 28, 2012 at 4:55 AM, Russell Keith-Magee > > wrote: > >> Have I missed part of the discussion here? At DjangoCon, South was > >> still going to exist (as the "smarts" part of the problem) -- has this > >> changed? > > > > Obviously nothing's really decided, but I've been asking Andrew to > > push for getting full-blown solution into core. I just don't see the > > point in beating around the bush any more. The lack of a built-in > > schema migration tool in Django is a major wart, so let's just fix it. > > No disagreement from me that this is a big wart that needs to be > addressed. I just missed the memo about us merging the smarts bit into > trunk. > > Russ %-) > > -- > 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. > > -- 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.
Re: Schema Alteration update
On Fri, Sep 28, 2012 at 8:29 AM, Jacob Kaplan-Moss wrote: > On Fri, Sep 28, 2012 at 4:55 AM, Russell Keith-Magee > wrote: >> Have I missed part of the discussion here? At DjangoCon, South was >> still going to exist (as the "smarts" part of the problem) -- has this >> changed? > > Obviously nothing's really decided, but I've been asking Andrew to > push for getting full-blown solution into core. I just don't see the > point in beating around the bush any more. The lack of a built-in > schema migration tool in Django is a major wart, so let's just fix it. No disagreement from me that this is a big wart that needs to be addressed. I just missed the memo about us merging the smarts bit into trunk. Russ %-) -- 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.
Re: Schema Alteration update
On Fri, Sep 28, 2012 at 4:55 AM, Russell Keith-Magee wrote: > Have I missed part of the discussion here? At DjangoCon, South was > still going to exist (as the "smarts" part of the problem) -- has this > changed? Obviously nothing's really decided, but I've been asking Andrew to push for getting full-blown solution into core. I just don't see the point in beating around the bush any more. The lack of a built-in schema migration tool in Django is a major wart, so let's just fix it. Jacob -- 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.
Re: Schema Alteration update
On Wed, Sep 26, 2012 at 7:14 PM, Andrew Godwin wrote: > So, the patch [1] is looking alright, but after some consideration I think > it's going to be best to leave this until just after the 1.5 branch has > happened and then merge it in as part of the 1.6 cycle. > > My reasoning is thus: > > - The whole point of getting something into 1.5 was so I could build > migrations as a third-party app. Since I now plan to make it more tightly > integrated, that's no longer useful. Have I missed part of the discussion here? At DjangoCon, South was still going to exist (as the "smarts" part of the problem) -- has this changed? > - The current patch is a bit ugly with the way it deals with AppCache - > discussion has led to a better, less hacky solution of implementing models > in a way where they can register into a different app cache. This point by itself strikes me as a good reason to punt to 1.6; Preston's patch for the app refactor is *almost* ready, and it's going to have some pretty profound implications for this point. > - It makes more sense to have the schema alteration, Field API changes and > migration runners all come out at once as otherwise it's not really a > user-facing solution. Agreed. > Thus, I'd like to wait until 1.5 is branched off, and then merge in an > improved patch which has better support for making models that don't > register themselves, following that up at some point in the 1.6 cycle with > patches that implement a new field description API (so fields can be > serialised in a more human-readable way than pickle) and then finally the > migration runner/dependency solver, meaning 1.6 would ship with a full > migrations system in place. > > Input on this plan is welcome - I just didn't want to rush something in when > it can be more polished and useful next release! It also means that this can > hopefully be integrated more smoothly with app-loading when that lands. I has a sad, but I understand why. Sounds like a reasonable approach to me. Russ %-) -- 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.
Schema Alteration update
So, the patch [1] is looking alright, but after some consideration I think it's going to be best to leave this until just after the 1.5 branch has happened and then merge it in as part of the 1.6 cycle. My reasoning is thus: - The whole point of getting something into 1.5 was so I could build migrations as a third-party app. Since I now plan to make it more tightly integrated, that's no longer useful. - The current patch is a bit ugly with the way it deals with AppCache - discussion has led to a better, less hacky solution of implementing models in a way where they can register into a different appcache. - It makes more sense to have the schema alteration, Field API changes and migration runners all come out at once as otherwise it's not really a user-facing solution. Thus, I'd like to wait until 1.5 is branched off, and then merge in an improved patch which has better support for making models that don't register themselves, following that up at some point in the 1.6 cycle with patches that implement a new field description API (so fields can be serialised in a more human-readable way than pickle) and then finally the migration runner/dependency solver, meaning 1.6 would ship with a full migrations system in place. Input on this plan is welcome - I just didn't want to rush something in when it can be more polished and useful next release! It also means that this can hopefully be integrated more smoothly with app-loading when that lands. Andrew -- 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.