Re: Idea/request for help: Django Developers Community Survey

[Mark Bailey]

I think the survey is a great idea.

Following on from Shai's question "one big project, or many small ones?"... 
I am the latter, so the "which version" doesn't really work for me even 
with multiple answers allowed.  I tend to:
 . Start each new project with the latest stable version.
 . Upgrade existing projects to latest stable version if I'm doing major 
rework (and have time to deal with any upgrade issues).
 . Leave well alone for projects that are running happily.
 . I don't have any really old projects, but I'll keep them all on 
supported versions.

Splitting into 2 questions would be one way to capture this.  Maybe:

When starting a new project which version of Django you use:
 [ ] I use the latest long-term support release.
 [ ] I use the latest stable version.
 [ ] I run off of master.
 [ ] I use a "favourite" version.

For existing projects when do you upgrade Django:
 [ ] When there is a new long-term support release.
 [ ] When there is a new stable version.
 [ ] I run off of master.
 [ ] When I want a new feature.
 [ ] When I am working on that project again.
 [ ] When the version I am using is nearing the end of its support (or 
after).
 [ ] I don't bother upgrading Django, even if it becomes unsupported.

Cheers,

Mark.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a176c0d-8d8a-4edc-8ca0-97ed05a2c9ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting database default values in migrations (postgres)

[Andrew Godwin]

Hi Sam,

That was also my idea for some time during development; I'm open to the
idea, though it does mean bringing database defaults into Django as an
overall concept, with all that that entails (e.g. documenting which default
takes precedence; dealing with database-specific defaults; how to represent
SQL functions; etc.).

If you're interested in whipping up a rough proposal, though, I'd be happy
to look over it - people have been asking for this since migrations came
around (and long before, too), as while Django never needs DB defaults
anything else using the database does (plus some concurrency issues with
default functions can be solved by moving them to the DB layer).

Andrew

On Sun, Apr 26, 2015 at 1:09 PM, Sam Baron  wrote:

> Greetings, I know this is an old thread, but it's an issue I am coming up
> against and hopefully I can restart the conversation.  I do think it's
> important that we use as many native database features as possible for
> application portability, extensibility, and performance.
>
> I have a different solution to the database default problem.  Why not
> handle it like SQLAlchemy?  There are two field properties for default -
> one applied at model instance (current Django default behavior) and one
> sent to the database.  In SQLAlchemy, it's called 'server_default', but for
> Django, I think 'db_default' would be a more appropriate name.
>
> So for example:
> integer_column = models.IntegerField(default=0)
> OR
> integer_column = models.IntegerField(db_default="0")
>
> And I agree that callables would not be included in 'db_default'.  This
> new property would only be for pushing SQL.  With this solution, I think
> you avoid user errors by keeping the two defaults behavior separate.  Only
> the advanced database folks will end up using it.
>
> I have made the relatively minor code changes on my end.  I am in the
> process and starting a new project and will keep testing it out.  I am
> curious if this would be an acceptable solution.
>
> Thanks,
> Sam
>
>
> On Saturday, November 1, 2014 at 10:17:50 AM UTC-7, Shai Berger wrote:
>>
>> On Friday 31 October 2014 19:16:15 Jon Dufresne wrote:
>> > On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin 
>> wrote:
>> > > So, bear in mind that you can easily set these defaults yourself in a
>> > > migration with RunSQL if you need them for legacy purposes; that way
>> > > they'll get applied
>> >
>> > Absolutely. I effectively have such a system in place at the moment.
>> >
>> > But, my point is I am also making an effort to match Django's expected
>> > schema while moving away from the legacy schema. I would prefer not to
>> > drift too far from Django's expectations as the goal is move entirely
>> > to Django. This is just one more thing to keep track of and handle
>> > semi-manually.
>> >
>> > All I'm saying is that if the described feature existed, it would
>> > benefit me and others that share my use case.
>>
>> So, we should be weighing the support-transition-from-legacy use-case
>> against
>> creating a situation where field defaults get a special treatment if they
>> are
>> primitive enough (callables are out, but I am really not sure about other
>> complex objects -- GIS would probably gain a new dimension of fun if it
>> were
>> to deal  with defaults, even when not callable).
>>
>> I think the correct way forward for migrations is to keep as it does
>> today --
>> requiring users to explicitly ask for db defaults (we could, as I said
>> earlier, give it a nicer API than RunSQL).
>>
>> As for "Django's expectations" -- while I don't think we should generate
>> db
>> defaults unless specifically asked to, I don't see where such defaults
>> could
>> get in our way. If you ever run into a situation where Django mishandles
>> some
>> table because it has defaults, that is almost for sure a bug.
>>
>> My 2 cents,
>> Shai.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e7d99cf6-c6a5-4d32-994c-7dd4e07ad478%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@g

Re: Must a Django Database Support Migrations?

[Andrew Godwin]

Hi Marcin,

I originally started developing the new Django migrations as a
contrib-style app, but for reasons of complexity and maintenance, they were
best moved into the database core itself - I can describe them at length if
you like, but trust me that I tried to keep things as cleanly separable as
possible where it made sense.

In fact, even now the migrations framework is built as separable, clean
components - the schema alteration backend is very much separate from the
migration file reader and writer, and it wouldn't be too hard to build an
alternate migrations framework that used the schema alteration backend
(which is essentially the common shared hard work of abstracting how to
make changes to databases across all backends we support) but completely
ignored the migration file stuff and overrode the existing commands.

You can't "turn off" the migration support in the same way you can't "turn
off" syncdb in 1.6 and below - they're the core way Django ships with of
making tables (and now, modifying them). What you can do, though, is
entirely override the behaviour with something custom if you so wish - it
wouldn't be too difficult to build something that overrode migrate to just
make tables the old way (using the new schema alteration backend). If
someone's willing to pay me some consulting time I'll write it for them,
with the caveat that it's probably not what anyone wants.

If there's a place in the migrations right now that's hard to override (for
example, I imagine the check in runserver for unmade migrations might be
something like this) I'm happy to take those as bugs as fix them, but
asking to remove migrations from core is like asking us to ship a broken
product - they're not there in addition to syncdb/Creation classes, they
replaced them with cleaner, more featureful code.

Andrew

On Mon, Apr 27, 2015 at 1:33 AM, Marcin Nowak 
wrote:

> Hi.
>
> Before v1.7 there were no migrations and Django was quite useful (for
> example with South as an 3rd party app). What happened then?
>
> I think that migrations can be decoupled from core and you just don't want
> to do this for some unknown reason.
> I'll prepare a pull request if it will not be dropped because of some kind
> of ethos.
>
> BR
> Marcin
>
> On Saturday, April 18, 2015 at 5:03:39 AM UTC+2, Markus Holtermann wrote:
>>
>> Hey Marvin,
>>
>> Unfortunately this won't work as a few migration components are tightly
>> integrated into remaining parts of Django, e.g. the field deconstruction.
>>
>> /Markus
>>
>> On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak <
>> marcin@gmail.com> wrote:
>> >Hi.
>> >Just give people possibility to disable migrations functionality
>> >(remove it
>> >from core and put as a contrib app, if needed).
>> >
>> >/BR
>> >Marcin
>> >
>> >
>> >On Thursday, January 22, 2015 at 8:09:01 PM UTC+1, Andrew Godwin wrote:
>> >>
>> >> Aha! Then, I would suggest redesigning MigrationRecorder to only make
>> >the
>> >> table when an actual recording operation is done, and have it swallow
>> >the
>> >> table not existing as "no migrations applied" the rest of the time,
>> >if
>> >> people think that seems sensible.
>> >>
>> >> Andrew
>> >>
>> >> On Thu, Jan 22, 2015 at 10:44 AM, Markus Holtermann <
>> >> in...@markusholtermann.eu > wrote:
>> >>
>> >>> Hey,
>> >>>
>> >>> as soon as the MigrationRecorder is used there is a call to
>> >>> "ensure_schema" that forces the creation of the migration table. The
>> >
>> >>> runserver command (among others?) checks for unapplied migrations
>> >and thus
>> >>> creates the migration table.
>> >>>
>> >>> /Markus
>> >>>
>> >>> On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin
>> >wrote:
>> 
>>  Hi Ivan,
>> 
>>  I'm not sure what you're asking here - are you asking to have a way
>> >to
>>  not have Django create the migrations recording table? I was under
>> >the
>>  impression that it was only created when migrate was run (at least,
>> >that
>>  was my original intention) so if you're managing your own schema
>> >just don't
>>  run migrate. Is there something else that's not working right, or
>> >is that
>>  being made too optimistically?
>> 
>>  Andrew
>> 
>>  On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel 
>> >wrote:
>> 
>> > From Andrew: "The only extra thing it would achieve is not having
>> > Django record migrations in the django_migrations table"
>> >
>> > The Django Users thread on how to keep this table from being
>> >created
>> > seemed to result in the 'solution' being either to stay with 1.6
>> >or comment
>> > the relevant lines in the Django code base. Is there really no
>> >other way?
>> >
>> > I love the new migrations facilities in Django 1.7 and was a
>> > contributor to the kickstarter but please keep in mind that many
>> >legacy DB
>> > projects are not avoiding migrations because they want to. IMO
>> >it's usually
>> > because they are forced to for

Allow deferral of ModelSignal callback invocation until after transaction commit

[Christopher Adams]

So wrote an 

RFC 

 and a prototype 

 
branch in Django to defer the invocation of certain handlers registered 
with Django model signals optionally until after transaction commit. Any 
thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ea261236-75cb-4902-8281-f39f3e4aabc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tino de Bruijn]

Hi,

Mark, I tend to do the same. Your proposed split of that question makes
sense to me.

Maybe a bit onto the details, but the last question about leaving an email
adres ("If you'd like to enter your name and email address so we can
follow-up if we have any questions about your responses. Please enter that
information below.") is a little oddly constructed...

Tino

On Mon, Apr 27, 2015 at 10:32 AM, Mark Bailey 
wrote:

> I think the survey is a great idea.
>
> Following on from Shai's question "one big project, or many small
> ones?"... I am the latter, so the "which version" doesn't really work for
> me even with multiple answers allowed.  I tend to:
>  . Start each new project with the latest stable version.
>  . Upgrade existing projects to latest stable version if I'm doing major
> rework (and have time to deal with any upgrade issues).
>  . Leave well alone for projects that are running happily.
>  . I don't have any really old projects, but I'll keep them all on
> supported versions.
>
> Splitting into 2 questions would be one way to capture this.  Maybe:
>
> When starting a new project which version of Django you use:
>  [ ] I use the latest long-term support release.
>  [ ] I use the latest stable version.
>  [ ] I run off of master.
>  [ ] I use a "favourite" version.
>
> For existing projects when do you upgrade Django:
>  [ ] When there is a new long-term support release.
>  [ ] When there is a new stable version.
>  [ ] I run off of master.
>  [ ] When I want a new feature.
>  [ ] When I am working on that project again.
>  [ ] When the version I am using is nearing the end of its support (or
> after).
>  [ ] I don't bother upgrading Django, even if it becomes unsupported.
>
> Cheers,
>
> Mark.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5a176c0d-8d8a-4edc-8ca0-97ed05a2c9ba%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANQFsQB5tP1SObYmLatqw_-EkhU-mezH6JaCGmAeMazLpDUnfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

[Carl Meyer]

Hi,

On 04/27/2015 08:17 AM, Christopher Adams wrote:
> So wrote an
> RFC
> 
>  and a
> prototype
> 
> branch in Django to defer the invocation of certain handlers registered
> with Django model signals optionally until after transaction commit. Any
> thoughts?

Thanks for putting the work into writing up this clear proposal, with
prototype code!

I agree that it would be good to have the ability in Django to run code
after-commit, but I think that feature is more useful it it's not
coupled to the signals framework. It would be better to have a generic
way to say "run this code after the current transaction commits"; then
it's equally easy to make use of that hook in a model signal handler or
elsewhere.

I wrote django-transaction-hooks [1] to serve this use case. I think
probably something like django-transaction-hooks should be part of
Django core. I'd be interested in any feedback you have on it.

Carl

[1] https://django-transaction-hooks.readthedocs.org/en/latest/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/553E8942.8060300%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Idea/request for help: Django Developers Community Survey

[Thorsten Sanders]

I wrote in that thread too why I dont like such fast releases and at 
least someone else asked too to give more options on that one question, 
on the developer mailing list its kinda only some people who are writing 
not reflecting all the developers such an survey maybe reach more of 
them and then the answer about such an important question shouldnt be 
reduced to 3 little options a handfull people decided on, that wouldnt 
reflect what people really want if they cant choose an real answer.


Am 27.04.2015 02:46, schrieb Tim Graham:
The idea of the release schedule question is to form consensus on the 
options that have already been proposed in the "1.9 release planning 
" 
thread. If you have a different idea, please propose it there.


On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote:

I like the idea of an survey, but find the release question with
only 3 options quite limited, how about to allow there to put own
numbers instead of giving fixed answers or at least an other field?

Am 25.04.2015 14:29, schrieb Tim Graham:

Aymeric and I put together a draft:


https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform



All questions are optional so you can just click through it to
view the questions. We'll probably clear any responses before its
finalized anyway.

Let us know if you think we should make any additions or changes.

On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico
Capoano wrote:

Great idea.
The questions look good enough to me.

I love django-apps or libraries shipped in python packages.
One of the reason I love Django is the fact that it didn't
frenetically add stuff to the framework just because it's cool.
The good thing of python packages is that you can get some
data from pypi (downloads) and github (clones). But we can't
do that with contrib apps unfortunately.

Federico


On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham
wrote:

I had an idea to conduct a survey to get a sense of how
developers are using Django. I first had the idea when
the question of maintenance of the Oracle GIS backend
came up. We really have no idea whether or not anyone is
actually using that backend, and it would be helpful to
know so we are not wasting resources on unused features.
Also there's the question of how often to release Django.
I think it would be nice to make that decision based on
some data from the community.

Is anyone is interested in coordinating such a survey
(collating questions, preparing the online survey, etc.).

Some question ideas to get started:

Which database backend(s) do you use?
[ ] Checkbox for each one

Which contrib apps do you use?
[ ] Checkbox for each one

How often would you like to see new major version of
Django released?
[ ] List some options, probably between 6 and 9 months.

Describe which version of Django you use (check all the
apply):
[ ] I only use long-term support releases.
[ ] I upgrade to the latest stable version as quickly as
possible.
[ ] I run off of master.
[ ] I upgrade Django when the version I am using is
nearing the end of its support (or after).
[ ] I don't bother upgrading Django, even if it becomes
unsupported.

-- 
You received this message because you are subscribed to the

Google Groups "Django developers (Contributions to Django
itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-develop...@googlegroups.com .
To post to this group, send email to django-d...@googlegroups.com
.
Visit this group at
http://groups.google.com/group/django-developers
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/f14071d1-c570-483a-abd2-833e1b47ab4d%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

[Aymeric Augustin]

> On 27 avr. 2015, at 16:17, Christopher Adams  
> wrote:
> 
> So wrote an  
> RFC
>  
> 
>  and a prototype 
> 
>  branch in Django to defer the invocation of certain handlers registered with 
> Django model signals optionally until after transaction commit. Any thoughts?


Hi Christopher,

Thanks for working on this. In addition to what Carl said, have you read 
https://code.djangoproject.com/ticket/21803 
 and 
https://code.djangoproject.com/ticket/14051 
? I think they’re relevant here.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CC456857-820D-45EB-A515-F62007041ABB%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.