Schema Alteration update

[Andrew Godwin]

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

[Russell Keith-Magee]

On Wed, Sep 26, 2012 at 7:14 PM, Andrew Godwin <and...@aeracode.org> 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 %-)

[Jacob Kaplan-Moss]

On Fri, Sep 28, 2012 at 4:55 AM, Russell Keith-Magee
<rus...@keith-magee.com> 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

[Russell Keith-Magee]

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 %-)

[Andrew Godwin]

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

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Luke Plant]

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/

[Andrew Godwin]

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

[Andre Terra]

On Fri, Oct 12, 2012 at 4:00 AM, Andrew Godwin <and...@aeracode.org> 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