Re: The model API and strong typing

On Saturday 01 March 2014 19:07:08 Aymeric Augustin wrote: > On 1 mars 2014, at 09:14, Martin Matusiak wrote: > > Now in the case of sqlite, which is very permissive, it will happily > > accept values like 1 and {} and store them as "1" and "{}" (wtf) > > respectively. So if I'm running my tests a

Re: index_together should also have the same convinience as unique_together

On Sunday, 2 March 2014 03:56:13 UTC+11, Aymeric Augustin wrote: > > On 1 mars 2014, at 13:16, Christian Schmitt > > > wrote: > > > I mean some pull requests are open since two years. Why don’t you close > them, when they won’t apply anymore? > > Because it feels aggressive to the people who

Re: 1.6 reverse() escapes unreserved chars in path components

On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai wrote: > The relevant commit and issue - > > https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7 > https://code.djangoproject.com/ticket/13260 Yes I saw that, but I'm confused. I thought these characters are allowed unescaped in

Re: The model API and strong typing

On Sun, Mar 2, 2014 at 1:07 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 1 mars 2014, at 09:14, Martin Matusiak wrote: > > > Now in the case of sqlite, which is very permissive, it will happily > > accept values like 1 and {} and store them as "1" and "{}" (wtf) > > resp

Re: 1.6 reverse() escapes unreserved chars in path components

The relevant commit and issue - https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7 https://code.djangoproject.com/ticket/13260 On 1 March 2014 17:26, Erik van Zijst wrote: > Django's django.core.urlresolvers.reverse() seems to have changed its > behavior in 1.6. It

Re: index_together should also have the same convinience as unique_together

This is now fixed in bb2ca9f . PR : #2381 Regards, Anubhav Joshi IIT Patna -- You received this message because you are subscribed to the Google Groups "Django develop

Re: The model API and strong typing

On 1 mars 2014, at 09:14, Martin Matusiak wrote: > Now in the case of sqlite, which is very permissive, it will happily > accept values like 1 and {} and store them as "1" and "{}" (wtf) > respectively. So if I'm running my tests against sqlite I won't even > know that this will bite me in produc

Re: index_together should also have the same convinience as unique_together

On 1 mars 2014, at 13:16, Christian Schmitt wrote: > I mean some pull requests are open since two years. Why don't you close them, > when they won't apply anymore? Because it feels aggressive to the people who submitted the pull requests. > It looks like no Core Developer is willing to clean t

Re: The model API and strong typing

On Mar 1, 2014, at 9:14 AM, Martin Matusiak wrote: > Is there a rationale for why we don't do this? Perhaps because handling data constraint is the db job? In the case of sqlite, which is very free form, simply define the proper check constraints. For example: create table foo ( bar text

The model API and strong typing

Hi django-dev, I have often come across bugs in code where attributes of a model instance were being assigned invalid values like None. Later on someone tries to save the model which blows up with an IntegrityError. Say you have a model like this: class User(models.Model): name = models.Char

Re: index_together should also have the same convinience as unique_together

Hi, Currently It doesn’t look so. I mean some pull requests are open since two years. Why don’t you close them, when they won’t apply anymore? It looks like no Core Developer is willing to clean them, etc… I mean a lot of new features are coming, but it doesn’t look like old things getting clean

Trac spam

Hello, If you've subscribed to django-updates, you must have noticed that spam levels have increased badly over the last weeks. The spam filters are fending off about a thousand spam attempts a day, but a small fraction (0,1-0,5%) gets through. Of course, we're deleting it as soon as we see it

Re: index_together should also have the same convinience as unique_together

Hi, there is no need to mail django-developers when you open a PR -- we do monitor the relevant lists. Cheers, Florian -- 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

Re: problem with testing for DeprecationWarning

On 1 mars 2014, at 10:51, Erik Romijn wrote: > Curiously, when I run this test independently, or when I run utils_tests > independently, this test succeeds. Perhaps there is some interaction with > other tests in the suite? If that's the problem, ./runtests.py --bisect utils_tests should tell

problem with testing for DeprecationWarning

Hello, I've started working on #22130, the deprecation of fix_ampersands, but I'm running into some trouble with building the tests. I imagine there's someone on this list with more experience in this, who might be able to help. My current patch is at https://github.com/erikr/django/compare/de

index_together should also have the same convinience as unique_together

"For convenience, unique_together can be a single tuple when dealing with a single set of fields" This convinience is missing in index_together: I have opened a PR, please see: https://github.com/django/django/pull/2381 Regards, Anubhav Joshi IIT Patna -- You received this message because yo

Re: index_together should also have the same convinience as unique_together

Related : https://code.djangoproject.com/ticket/22172 -- 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 pos