Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On 11/20/2014 11:07 AM, Andrew Godwin wrote: > (also, I had an idea on the way back that perhaps we could derive the > random element from the migration name, making it different across > different migrations so they don't clash but still the same across runs, > but I'm not sure how you'd access th

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Just chiming in on this; I sat down with Tom to look at this during the sprint, and while we could go to a large amount of effort to try and rename indexes on every rename of a model/field, the problem is solved much more easily by introducing a random element to index names. This does, of course,

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

I don't think that spreading add_error to more places really helps with the "more than one way to do it" issue - raising ValidationError isn't going anywhere as documented public API. It's still the simplest thing to do from a clean_field method, or if you want the error in non_field_errors. I rea

Re: Configurable safety options for high performance Django systems

On Thursday, November 20, 2014 8:31:06 AM UTC+1, Christian Schmitt wrote: > > Nope. a large OFFSET of N will read through N rows, regardless index >> coverage. see >> http://www.postgresql.org/docs/9.1/static/queries-limit.html >> > > That's simple not true. > If you define a Order By with a well

Re: Handling "Save with update_fields did not affect any rows"

Hi Jeroen, On 11/20/2014 02:43 AM, Jeroen Pulles wrote: > I'm still wondering what's best for save_table to do. Pre-1.6 Django > code would end up with a new object in my situation, and no complaints. > Apparently, that worked, for me. I'm inclined to think that is still > what I want for the upda

Re: Configurable safety options for high performance Django systems

2014-11-20 8:30 GMT+01:00 Schmitt, Christian : > Nope. a large OFFSET of N will read through N rows, regardless index >> coverage. see >> http://www.postgresql.org/docs/9.1/static/queries-limit.html >> > > That's simple not true. > If you define a Order By with a well indexes query, the database w

DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hi all, At the Django under the hood sprint I picked up #23577 which says, in the general case: 1. For any database object when django creates an associated index 2. If you rename that object 3. Then re-create another with the original's n

Re: Handling "Save with update_fields did not affect any rows"

Hi Carl, Thanks for taking the time to respond. I'm still wondering what's best for save_table to do. Pre-1.6 Django code would end up with a new object in my situation, and no complaints. Apparently, that worked, for me. I'm inclined to think that is still what I want for the update-y variant

Re: 'Manager isn't available; User has been swapped for 'register.User''

Hello Ajay, > On 20 Nov 2014, at 06:20, Ajay Kumar wrote: > > hi guys. I'm in a django project , i tried to customize the user table model > and tried to add a field gender in it and added success fully ,as per the > instruction i followed changes and got gender field in it.but when i tried to

Content-Security-Policy header for Django 1.8 SecurityMiddleware

Hi, The SecurityMiddleware in Django 1.8 currently lacks one of the most powerful HTTP headers to limit what browsers allow. When correctly configured is helps to prevent XSS and other (injection) attacks. At the Django Under The Hood sprint (which was an awesome event!) I wrote a pull request