Re: Schema Alteration update

[Andre Terra]

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

[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

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

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

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

[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

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

[Russell Keith-Magee]

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

[Jacob Kaplan-Moss]

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

[Russell Keith-Magee]

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

[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

-- 
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.