Quoting django-developers@googlegroups.com (2013-05-31 07:39:24)
> From: Andrew Godwin
> Date: May 30 07:03PM +0100
> Url: http://groups.google.com/group/django-developers/msg/137ab14f361fd052
>
> 2. Leave syncdb as it is, like South does, and have everything happen
> through a "migrate" command.
On Fri, May 31, 2013 at 2:03 AM, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in
> Django, and I've hit something of an impasse trying to decide which option
> to go for.
>
> Short background: South modified syncdb to just sync non-mig
I haven't used South as much as I should have (instead I have painful
> manual scripts to do migrations). The biggest pain point about
> database schemas for me is easily test database setup. That is, sync
> from scratch. I do the following currently:
> 1. load schema + a little bit of data from
+1 on option 3.
In hindsight syncdb isn't a good name. It won't be missed. Please deprecate it.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
On 30 touko, 21:03, Andrew Godwin wrote:
> I prefer option 3, but getting rid of syncdb might be controversial, so I
> want to ask for people's opinions. syncdb would continue to exist for at
> least 3 versions if not forever; it would just be an alias to run "migrate"
> in its default configurati
Hi all,
On Thursday 30 May 2013, Andrew Godwin wrote:
>
> The proposals are:
>
> 1. Change syncdb so that it both does the old behaviour (adds models for
> unmigrated apps), and additionally runs any outstanding migrations. There
> would be a separate "migrate" command for more complex operatio
On 30.05.2013, at 20:03, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in Django,
> and I've hit something of an impasse trying to decide which option to go for.
>
> Short background: South modified syncdb to just sync non-migrated
On 05/30/2013 12:03 PM, Andrew Godwin wrote:
> The proposals are:
>
> 1. Change syncdb so that it both does the old behaviour (adds models
> for unmigrated apps), and additionally runs any outstanding migrations.
> There would be a separate "migrate" command for more complex operations,
> such as
I'm broadly +1 on deprecating syncbd, it's possibly the most inaccurately
named thing in all of Django (hint: it doesn't sync anything).
Alex
On Thu, May 30, 2013 at 11:03 AM, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in
> Django
On May 30, 2013, at 2:03 PM, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in Django,
> and I've hit something of an impasse trying to decide which option to go for.
>
> Short background: South modified syncdb to just sync non-migra
Hi everyone,
I'm starting to plan out the commands for the new migrations stuff in
Django, and I've hit something of an impasse trying to decide which option
to go for.
Short background: South modified syncdb to just sync non-migrated apps, and
you had to go and run migrate separately to get migr
Sorry I'm late back to the party boys and girls.
Trivial as it may be, it's really just communication that's the only issue
here, and I'm glad this has prompted a review. We all mean well and we're
eager to help. The solutions Cal, Russ, Luke and co have discussed sound
great.
BTW- there are
>
> I must say that reading this into Russel (and other)'s replies is very
> far fetched (language as well as content), uncalled for, and seems to
> expose an assumption that the people here prefer the easy path of swatting
> suggestions with a quick "nay". I 'd say the opposite is much close
Hello Jorge,
On Thu, 30 May 2013 12:42:20 +0300, Jorge C. Leitão
wrote:
Hi Russell Keith-Magee.
Thanks for your criticisms. Let's see if I can answer some of them.
I'd turn this question back onto you -- why *should* the search start
locally? What collisions are you seeing between apps t
Hi Russell Keith-Magee.
Thanks for your criticisms. Let's see if I can answer some of them.
> I'd turn this question back onto you -- why *should* the search start
> locally? What collisions are you seeing between apps that makes a global
> search impractical?
Very good question! I think t
On 30 May 2013 10:20, Jorge C. Leitão wrote:
>
> On Thursday, May 30, 2013 7:54:40 AM UTC+2, Shai Berger wrote:
>>
>
> Why python allows nested apps?
Python allows nested *modules* because namespaces are good. Also
because without it you would have to wither write every module in a
single file or
Hi Shai Berger and thanks for your quick response.
Regarding your criticisms,
On Thursday, May 30, 2013 7:54:40 AM UTC+2, Shai Berger wrote:
>
> Actually, Django doesn't. That is, an app is a Python package, and Python
> packages can be nested, so you can have app 'b' within app 'a', and in
> y
17 matches
Mail list logo
