Re: [Review Request] Added support for database delegated fields (like AutoField)

On Monday, February 1, 2016 at 10:33:26 AM UTC+2, Aymeric Augustin wrote: > > > On 31 janv. 2016, at 22:55, Shai Berger > wrote: > > > > Your message seems to be confusing the queryset API with the > model-instance > > API. > > Oops :-( > > Anyway, it seems that we

Re: Extending ModelForm.save_m2m

Sure, my bad, this is the example with form_business, a GFK, before / after: https://gist.github.com/jpic/c6a16723db62f779848f If we make it to encapsulate value_from_object / save_form_data elsewhere than in the model field then it will allow form fields and forms used in the admin to do more.

Re: Extending ModelForm.save_m2m

I'm trying to understand what you're trying to accomplish at a very basic level. I'm not familiar with any of the third-party packages you mentioned. How will the proposed changes in Django simplify them? In your second mail you proposed a "form_business" kwarg with a "YourFormBusiness"

Re: Extending ModelForm.save_m2m

Thanks for the advice, I started trying moving form-related stuff from FieldBase into a new ModelFormFieldBase class, and it turns out that there's a lot more we could, or should, move than just value_from_object and save_form_data. Why not move out everything that couples the form field and the

Re: Extending ModelForm.save_m2m

Your description is a bit abstract for me to understand. Could you put together a before (how the code looks now) and after (how the code would look with this feature) for an example use case? On Monday, February 1, 2016 at 2:30:15 PM UTC-5, is_null wrote: > > Hi all, > > My understanding of

Re: Extending ModelForm.save_m2m

Hi all, My understanding of the design issue I'm facing was too approximative at the time I opened this topic, sorry about that. The way I understand it now, is that we have only 2 moving parts but 3 features: - input validation in the form field, - business logic in the model field, - problem:

Re: Adding SASL authentication support to PyLibMCCache

I found an old discussion about it, but it didn't attract much interest at the time: https://groups.google.com/d/topic/django-developers/pISp20wuu0E/discussion On Saturday, January 30, 2016 at 7:21:49 PM UTC-5, Ed Morley wrote: > > Hi > > For apps running on Heroku, two of the main memcached

Re: Deprecate Cache.has_key()?

We have django.utils.deprecation.RenameMethodsBase to help with that, but now I see that subclasses have this signature, `def has_key(self, key, version=None)`, so it doesn't seem the method can be replaced with __contains__. Proposal withdrawn. On Sunday, January 31, 2016 at 4:26:12 AM

Re: PostGres 9.5 Upsert

Hey--that's pretty slick. I'm not sure when we're going to take a shot at this implementation, but I'll keep that in mind. -Ben On Mon, Feb 1, 2016 at 7:12 AM, wrote: > It should be possible to use a "RETURNING" clause to get the new row even > in the instance of a

[ANNOUNCE] Django releases issued: 1.9.2 (security) and 1.8.9 (bugfix)

Today the Django team issued 1.9.2 as part of our security process. This releases address a security issue, and we encourage all users to upgrade as soon as possible. The Django 1.8.9 release fixes several bugs in 1.8.8 but no security issues as the issue fixed in 1.9.2 doesn't affect older

Re: PostGres 9.5 Upsert

It should be possible to use a "RETURNING" clause to get the new row even in the instance of a get_or_create. I occasionally use an UPDATE ... RETURNING query with Manager.raw to update a table and get modified instances in one shot. On Tuesday, January 12, 2016 at 12:54:03 PM UTC-6,

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

On 1 févr. 2016, at 12:20, Markus Holtermann wrote: > I think that links to 3rd party pages with grids, comparisons, pros'n'cons, > scattered all over Django's documentation aren't too helpful. I agree. I’m +0 on linking to Django packages on a page that talks about

Re: View permissions to admin

Hi, +1 for view permission and Petr's rationale There's one use case where missing the view permission should even be considered a bug: when you have foreign key with the raw id widget, currently the user gets a 403 error in the popup if he doesn't have edit permission on the related model.

Re: [admin] submit_row template tag reusability issue

Here is an accepted ticket: https://code.djangoproject.com/ticket/13875 Feel free to update and/or improve the patch, add tests, and send a pull request. Thanks! On Monday, February 1, 2016 at 6:18:35 AM UTC-5, Federico Capoano wrote: > > Hi all, > > I came across the need of modifying the

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

I think that links to 3rd party pages with grids, comparisons, pros'n'cons, scattered all over Django's documentation aren't too helpful. I'd probably prefer a separate page in the docs that links to those 3rd party pages. The general problem with those sites though, they are not audited for

[admin] submit_row template tag reusability issue

Hi all, I came across the need of modifying the submit row functionality in the django admin and I found out a small issue which prevents me from modifying the template without rewriting (duplicating) also the templatetag entirely. If you take a look at the code of submit_row templatetag

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

It seems like a good proposal, It would be good to know why Sergei doesn't think it is appropiate for Django to add links to third party package comparison grids. django-rest-framework links to third party extensions in its documentation and this had a positive effect on the whole DRF

Links from django docs to djangopackages.com should be 'officially endorsed' or not?

This ticket was closed as invalid: https://code.djangoproject.com/ticket/26159 {{{ Here comes a pull request to add a link to the djangopackages comparison grid "Pagination". Background: The pagination in django core is only very basic. Most people want more. I think re-use helps more then

Re: [Review Request] Added support for database delegated fields (like AutoField)

> On 31 janv. 2016, at 22:55, Shai Berger wrote: > > Your message seems to be confusing the queryset API with the model-instance > API. Oops :-( Anyway, it seems that we agree on: - controlling this behavior in the query rather than in the field definition — this avoids