Re: Switch to database-level autocommit
> I'd like to improve transactions handling in Django. The first step is the > current emulation of autocommit with database-level autocommit. > [...] > I don't see much point in providing an option to turn autocommit off, > because starting a transaction is a much more explicit way to achieve the > same effect. We usually don't provide "backwards compatibility with bugs". > > Yay or nay? > A definite yay from me! Cheers, Stephan -- 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 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: auth_permission column lengths
Hi Florian, Am 19.06.2012 um 16:12 schrieb Florian Apolloner: > Django itself can't change that currently since there is no support for > schema alteration in Core. Once we get that we can tackle issues like that > and increase to a sensible limit. (both name and codename might cause > problems…). How is this a factor if the limit exists only at the database level and is not enforced or considered in Django code? Django code already creates values that are too long for the fields. You would just eliminate this bug on new installations. In the case of usernames and email addresses, the limit was enforced in Django code, so increasing the field length could break existing installations since we can't do automatic schema migrations. But in this case, things already break since Django does not care about the field length. Cheers, Stephan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Revisiting multiline tags
>> 1) It's an easy fix. >> 2) It's backwards compatible. >> 3) It has no impact on performance. >> 4) LOTS of people want it. >> >> and most importantly >> >> 5) We could stop asking for it. >> >> This issue is such an easy "sure, why not!?" >> >> Please, O benevolent dictators, listen to the populous, and heed their >> cry. > > I can certainly appreciate the reasons why those asking for this change would > like to see the change made, but please don't attempt to characterize this > thread as clear and overwhelming support for change. > > This thread contains 6 people expressing support for this change, and 2 > against (a BDFL, a core developer) -- and you can add me to the -0 list. > There are over 6000 subscribers to django-developers. I put it to you that > the vast majority of people haven't expressed an opinion -- and many of those > haven't expressed an opinion because they're happy with (or indifferent to) > the status quo, and a BDFL has already indicated that the status quo is his > preferred option. You asked for it, so here is my +1. > This is also the first time the issue has been raised on django-dev for some > time -- I can't even remember the last time the subject was raised. If this > is such a demand of the populous, why isn't it a regular topic of discussion > on django-dev? Because the Django community is extremely nice and well-behaved...? :) I too was unhappy with the decision, but didn't feel it was important enough to post in this thread. That doesn't mean I wouldn't appreciate multiline tags. > Finally, your arguments in favor of making this change are almost entirely > technical -- easy fix, backwards compatible, no performance hit. However, > you've missed the non-technical aspects -- that introducing multiline tags > would fundamentally change the flavor of Django templates. Part of the job of > the BDFLs is to make aesthetic choices. As indicated by Adrian in his > response, this is largely an aesthetic decision on his part. Aesthetic > choices aren't always popular, and almost by definition won't make everyone > happy, but they are an essential part of what gives Django it's distinctive > flavor. Well, and you are really making the non-technical argument for the supporters, aren't you? If multiline tags would fundamentally change the flavor of Django templates, it would mean that suddenly people everywhere would start using them, massively. This would mean there is overwhelming demand for them. But if people do only use them in the cases where it's appropriate (e.g. the dreaded trans tag, multi-line comments and so forth) then it doesn't change much of anything and just makes templates more readable. I understand this is an aesthetic decision. I just wish to point out that you can't make the argument that nobody wants it and that it would also have a big impact. Cheers, Stephan -- 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.
Need help (testing/review) for patch
Hi everybody, I'm the author of the patch for bug 8660. [0] The patch adds user permission checking for admin inlines. Carljm has been very helpful at giving me pointers and reviewing the patch. But since he's very busy at the moment, it would be nice if someone else could try out the patch and verify that it does work as expected, or make sure that it doesn't break anything. Any feedback, either here or directly on the ticket, would be highly appreciated. Thanks, Stephan [0] https://code.djangoproject.com/ticket/8060 -- 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: ManyRelatedManager with explicit intermediary model
Hi Roald,
Am 20.09.2011 um 15:52 schrieb Roald de Vries:
> Hi all,
>
> Is there a fundamental reason that I'm missing (other than "nobody's taken
> the trouble of writing it") that I can't do the following? If there isn't
> I'll create a ticket for it.
>
>class R(Model):
>user = ForeignKey(User)
>my_model = ForeignKey('MyModel')
>comment = CharField(max_length=100, blank=True)
>
>class MyModel(Model):
>users = ManyToManyField(User, through=R, null=True)
>
>m = MyModel.objects.create()
>u = User.objects.create_user('roald', 'downa...@gmail.com', 'password')
>
>
># these things I can't do:
>m.users.add(u)
>m.users.add(u, comment='Blablabla')
https://docs.djangoproject.com/en/1.3/topics/db/models/#intermediary-manytomany
You can't use add() when specifying the intermediate model. You would have to
check all fields of the intermediate model and make sure all of them have
defaults or are allowed to be null. It might not be worth the trouble of
implementing it.
Cheers,
Stephan
--
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.
