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

[Anssi Kääriäinen]

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 agree on: 
>
> - controlling this behavior in the query rather than in the field 
> definition — this avoids the awkward “ignore what the field says” query 
> parameter 
> - trying not to provide separate APIs for insert and update behavior 
> - improving the save(update_fields=…) API to support inserts as well as 
> updates 
>

For the .save() method we could go with a new argument fields=[...]. The 
way it works is that only the mentioned fields are inserted or updated. If 
you want the current behavior of update_fields, set force_update=True.

The main reason why update_fields patch didn't ever try to target insert 
statements was that the feature didn't make much sense. We didn't have 
database defaults and we didn't have any other sort of expressions support 
for inserts. There was very limited use cases for skipping fields in 
insert. I'm not sure we have much of an use case now either (notably one 
can write DbDefaultExpression that compiles to sql, params = "default", [] 
already). What is the main use case for this feature?

I've been toying around with an idea that we add a non-data descriptor (one 
implementing just __get__) for all fields of an model, and use this for 
deferred loading. Currently we use dynamically created subclasses of the 
model which is a hack. The way this would work is that if an instance's 
__dict__ doesn't have any value for given field, then we interpret that 
field as deferred. This would also give a natural way to refresh a given 
field from DB. You would set a field "deferred" manually by "del 
instance.field", and after that instance.field would reload that field. The 
descriptor wouldn't cost much, as non-data descriptors don't add any 
measurable overhead when the attribute is set on the instance's __dict__. I 
think the feature would be backwards compatible (though without trying it 
is hard to be sure).

This feature would also allow skipping fields on insert: instance = 
MyModel(); del instance.some_field; instance.save() -> some_field is 
skipped as it is deferred; instance.some_field -> some_field is refreshed 
from DB. This would close the gap in the APIs.

I would like to see support for expressions that can tell Django the field 
should be skipped in update/insert and if the field should be refreshed 
from database after update/insert. This would give a nice low-level API for 
manipulating the behavior of save() and bulk_insert(). I don't see a need 
to mix this with the current pull request. The biggest problem for such 
expressions is that they don't make any sense when using a model. For 
example TransactionNow() isn't a nice value for last_update field in any 
other context than saving. Not sure this is a big enough problem to worry, 
but something to consider anyways.

Refreshable expressions would give a natural way for skipping fields on 
insert. Also, things such as database defaults would be easy to use with 
the ORM:

class DbDefault(Expression):
refresh_on_insert = True
refresh_on_update = True

def as_sql(self, compiler, connection):
return "default", []

my_instance = MyInstance(uuid=DbDefault())
print(my_instance.uuid) -> "DbDefault()"
my_instance.save()
print(my_instance.uuid) -> "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"  (or 
whatever the DB happens to generate)

 - Anssi

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5310c9fc-d26a-469b-9a9c-dcdd437195b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[James Pic]

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. One might raise the point that
there should only be one way for a form to get / provide data for a
model field. While that makes sense, perhaps a pragmatic way to change
it would be useful.

Note that currently, I've tested the first idea (extension to
modelform api) and maybe it's not that bad
https://github.com/yourlabs/django-autocomplete-light/blob/v3/src/dal/forms.py#L60

Perhaps another way (deviated from the extension to modelform api)
would be to have forms.models.ModelField classes, which would add the
retrieve / provide data for a models.fields.Field and have precedence
over the corresponding
models.fields.Field.{save_form_data,value_for_object}:
https://gist.github.com/jpic/c30724a5a90b258a312a

Please let me know if there's anything else I can do to help getting feedback

Thanks for your feedback

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kadkg%3D3osehZMXFzx7E0rPfwDLQVn5adiev5QUSAgRKONQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[Tim Graham]

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" argument 
without a description of what that class looks like. I'm sure I could 
understand more if I spent a lot of time looking into it, but please try to 
make it very easy -- you'll get more feedback this way.

p.s. not sure you meant by "FieldBase" -- there is no class in Django by 
that name.

On Monday, February 1, 2016 at 3:38:37 PM UTC-5, is_null wrote:
>
> 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 model 
> field in from FieldBase into ModelFormFieldBase while we're at it ? 
>
> I like this idea, are you more interrested in seeing a before / after 
> of 0. just moving value_from_object + save_form_data or 1. moving form 
> stuff from FieldBase into ModelFormFieldBase ? 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/908759b4-11bd-492b-b4c6-7b667c031292%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[James Pic]

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 model
field in from FieldBase into ModelFormFieldBase while we're at it ?

I like this idea, are you more interrested in seeing a before / after
of 0. just moving value_from_object + save_form_data or 1. moving form
stuff from FieldBase into ModelFormFieldBase ?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf0g9%2B3FTibtYyi2_2AW%2BSmD8jYD6oCYYXTeSh_gN4DUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[Tim Graham]

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 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: validated input to business logic is in the model field. 
>
> It seems like decoupling the third feature from the model field into 
> its own component would be the best way to achieve loose coupling and 
> make it replaceable. 
>
> This would enable a user to replace the input-business behaviour 
> (value_from_object(), save_form_data()). This Having such an 
> input-business in a model field **or a modelform field** would allow 
> changing it on a per-form basis while keeping it in the right place. 
>
> Examples would be: 
>
> class YourModel(models.Model): 
> test = GenericForeignKey('content_type', 'object_id', 
> form_business=YourFormBusiness) 
>
> Alternatively: 
>
> class YourModelForm(models.Model): 
> test = YourField(form_business=YourFormBusiness) 
>
> Advantages: 
>
> - Model fields still have default save_form_data/value_from_object but 
> it's decoupled in another class, 
> - Form field still don't do any business logic, they may just provide 
> an alternative one, 
> - Allows providing form fields for model fields which are not editable 
> by default, 
> - Allows encapsulating form field specific business logic in its own 
> class, 
>
> What do you think ? 
>
> Best 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ed42f674-ef72-40fa-8cb1-3a4f5fb01e58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[James Pic]

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: validated input to business logic is in the model field.

It seems like decoupling the third feature from the model field into
its own component would be the best way to achieve loose coupling and
make it replaceable.

This would enable a user to replace the input-business behaviour
(value_from_object(), save_form_data()). This Having such an
input-business in a model field **or a modelform field** would allow
changing it on a per-form basis while keeping it in the right place.

Examples would be:

class YourModel(models.Model):
test = GenericForeignKey('content_type', 'object_id',
form_business=YourFormBusiness)

Alternatively:

class YourModelForm(models.Model):
test = YourField(form_business=YourFormBusiness)

Advantages:

- Model fields still have default save_form_data/value_from_object but
it's decoupled in another class,
- Form field still don't do any business logic, they may just provide
an alternative one,
- Allows providing form fields for model fields which are not editable
by default,
- Allows encapsulating form field specific business logic in its own class,

What do you think ?

Best

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KacNBZo6ezHtyMLLzpRd95D9EFUaX_PUr%2B5Vz12RR7a%3Ddw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding SASL authentication support to PyLibMCCache

[Tim Graham]

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 options are 
> MemCachier and Memcached Cloud [1]. Both of these control access via SASL 
> authentication, which isn't supported by Django's current pylibmc backend 
> [2], even though pylibmc supports it [3]. As such, currently the 
> django-pylibmc backend has to be used instead [4].
>
> I'd like to add SASL auth support to the Django pylibmc backend to make 
> this unnecessary, which is just a case of passing the relevant parameters 
> through to the pylibmc client during its instantiation [5]. A previous 
> newsgroup discussion about this is at [6].
>
> SASL auth requires binary mode, so I'll also need to add support for that 
> - for which there is already a Django ticket filed [7].
>
> I have a couple of questions:
> a) Will a PR to add SASL authentication support be accepted?
> b) If yes to (a), should the `username`, `password` and `binary` fields be 
> added to the top level `CACHES['foo']` dict, or nested inside `OPTIONS` 
> within that? I'm presuming within OPTIONS? Examples: [8].
>
> Many thanks,
>
> Ed
>
> [1] https://elements.heroku.com/addons#caching
> [2] 
> https://github.com/django/django/blob/1.9.1/django/core/cache/backends/memcached.py#L181
> [3] 
> https://github.com/lericson/pylibmc/blob/1.5.0/src/pylibmc/client.py#L125
> [4] https://github.com/django-pylibmc/django-pylibmc
> [5] eg: 
> https://github.com/django-pylibmc/django-pylibmc/blob/v0.6.1/django_pylibmc/memcached.py#L85-L91
> [6] 
> https://groups.google.com/forum/#!searchin/django-developers/pylibmc/django-developers/pISp20wuu0E/tamJ1h8zCzsJ
> [7] https://code.djangoproject.com/ticket/15815
> [8] https://emorley.pastebin.mozilla.org/8858134
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9ab8eb77-28d2-47cc-a047-2e85835b2133%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate Cache.has_key()?

[Tim Graham]

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 UTC-5, Adam Johnson wrote:
>
> Might be problematic for third-party cache backends which implement 
> *has_key* and rely on *__contains__* calling it - don't see how you can 
> show the warning in that case.
>
> On Saturday, January 30, 2016 at 12:34:14 PM UTC, Tim Graham wrote:
>>
>> Yes, but dict.has_key() is removed in Python 3. If we started the 
>> deprecation in Django now, it would be scheduled for removal in Django 2.0 
>> which also drops support for Python 2.
>>
>> On Friday, January 29, 2016 at 8:04:33 PM UTC-5, Curtis Maloney wrote:
>>>
>>> Isn't this so it complies with the dict interface? True, it's 
>>> discouraged now, but it's still there.
>>>
>>>
>>>
>>> On 30 January 2016 10:42:12 am LHDT, Tim Graham  
>>> wrote:

 Also the template BaseContext class has an undocumented has_key() 
 method. I wonder if that can be removed without a deprecation?

 https://github.com/django/django/pull/6066

 On Friday, January 29, 2016 at 6:11:54 PM UTC-5, Tim Graham wrote:
>
> Any opposition to deprecating Cache.has_key()? Cache already 
> implements __contains__() so converting has_key() to "in" can be done 
> with 
> existing versions of Django. Anyone using flake8 will get a warning about 
> has_key() usage: W601 .has_key() is deprecated, use 'in'.
>

>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97220f93-8aaa-4183-bb52-b72fe1b2d787%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostGres 9.5 Upsert

[Ben Liyanage]

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 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, bliy...@rentlytics.com
> wrote:
>>
>> After thinking about it a bit, I think the only function that would
>> really benefit from this would be the update_or_create.  If you're doing
>> get_or_create you still need a second query to get the actual row.
>>
>> On Friday, January 8, 2016 at 4:13:26 PM UTC-8, bliy...@rentlytics.com
>> wrote:
>>>
>>> Hey Guys,
>>>
>>> Postgres 9.5 has added the functionality for UPSERT aka update or
>>> insert.  Any interest in aligning UPSERT on the db layer with the
>>> get_or_create or update_or_create functionality in django?  Sounds like my
>>> company would be interested in doing the work if the PR will get the
>>> traction.
>>>
>>> -Ben
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/swBPqFi-Tdk/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2b8db682-1b8d-4549-8d8c-f99f3d6b8f90%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.*
Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com
1132 Howard Street, San Francisco CA 94107
Visit our Website  | Watch our Video


-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADgLBUM%2B7DOCHLYiOvRh-XXRRWfWVOQUZ%3DrNprQ8f48D_7fm9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Graham]

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 versions.

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2016/feb/01/releases-192-and-189/

As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security for further information.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a40ec0ec-82c0-45d4-ac06-d24fa95313fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostGres 9.5 Upsert

[john . parton]

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, bliy...@rentlytics.com 
wrote:
>
> After thinking about it a bit, I think the only function that would really 
> benefit from this would be the update_or_create.  If you're doing 
> get_or_create you still need a second query to get the actual row.
>
> On Friday, January 8, 2016 at 4:13:26 PM UTC-8, bliy...@rentlytics.com 
> wrote:
>>
>> Hey Guys,
>>
>> Postgres 9.5 has added the functionality for UPSERT aka update or 
>> insert.  Any interest in aligning UPSERT on the db layer with the 
>> get_or_create or update_or_create functionality in django?  Sounds like my 
>> company would be interested in doing the work if the PR will get the 
>> traction.
>>
>> -Ben
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2b8db682-1b8d-4549-8d8c-f99f3d6b8f90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Aymeric Augustin]

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 the 
ecosystem of pluggable applications, -0 on linking to just a specific grid.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0643E38E-5C6A-47D6-B655-0E09BDB777B7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: View permissions to admin

[Olivier Dalang]

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.

Best,

Olivier


On 31 Jan 2016 17:10, "Petr Dlouhý"  wrote:

> Hi Markus, Adam,
>
> I looked to Django admin documentation (
> https://docs.djangoproject.com/en/1.9/ref/contrib/admin/). I don't see
> anything discouraging from such usage, but rather I see encouraging for
> usage as interface for content managers:
>
> "One of the most powerful parts of Django is the automatic admin
> interface. It reads metadata in your model to provide a powerful and
> production-ready interface that content producers can immediately use to
> start adding content to the site. In this document, we discuss how to
> activate, use and customize Django’s admin interface."
>
> I totally agree with that quote, Django admin is one of the top things
> that I love at Django. For it flexibility, easy development and usefulness.
> Why not to make Django strengthenesses even stronger? I use it in such ways
> and I am not aware about any "fiddling with the internals". The view
> permissions was first such case.
>
> If Django admin usage for such purposes is not intended, I would expect to
> see big fat warning as a first thing on that page.
>
> View permissions in admin seems to me as something very natural that is
> missing there. The implementation of that is very lightweight and nicely
> fitting - I mostly only added what was missing there. I wouldn't call that
> hacking.
> Yes, I was thinking of making an independent application, but that would
> probably be very difficult and would require to copy some code of the
> Django internals. That would require big hacking!
>
> 2016-01-31 17:49 GMT+01:00 Adam Johnson :
>
>> Hi,
>>
>> At YPlan we've hacked in view permissions to the admin, exactly because
>> of the reasons Markus talked about - it's the front end we've built for
>> employees, done rather than building a proper process-based interface. I
>> think it could just about be done in a third-party package (It might rely
>> on a patchy.patch  call though),
>> rather than incorporating it into Django - have you considered this? At
>> this point we're all in preference of a better toolbox for building
>> internal tools, as Markus is suggesting, rather than "improving" the admin.
>>
>> Adam
>>
>> On Thursday, January 28, 2016 at 6:17:26 AM UTC, Markus Holtermann wrote:
>>>
>>> Hi Petr, all,
>>>
>>> I managed to find some time to look into your PR (updated link:
>>> https://github.com/django/django/pull/5297) and the related issue:
>>> https://code.djangoproject.com/ticket/8936 .
>>> Also, related discussion:
>>> https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion
>>> and issues: https://code.djangoproject.com/ticket/820 and
>>> https://code.djangoproject.com/ticket/17295
>>>
>>> First of all, thank you for your your contribution and persistence.
>>>
>>> I think Django should provide an easy way to get a read-only view of
>>> your data in the database. However, I don't really like the integration
>>> into contrib.admin . As it stands now, people commonly use the admin as a
>>> front end for their employees instead of building a proper process-oriented
>>> interface. This may work to some degree but it's not uncommon that
>>> developers need to fiddle with the internals of the admin to make specific
>>> things work. Adding a read-only view to the admin would encourage people
>>> even more to use the admin for reasons where they shouldn't.
>>>
>>> I'd prefer an approach on a different level where Django gains a proper
>>> (de)serialization implementation. The implementation would e.g. leverage
>>> content negotiation to define the output, e.g. JSON, XML, HTML, etc.
>>>
>>> What I'm pretty much saying is, I'd rather see a proper django.rest (or
>>> whatever we wanna call it) instead of a feature on top of the convoluted
>>> admin which provides only half of what people probably want and use.
>>>
>>> Cheers,
>>>
>>> /Markus
>>>
>>> On Wednesday, August 26, 2015 at 9:49:58 PM UTC+10, Petr Dlouhý wrote:

 Hello all,

 I am still waiting for some information about what should I do next to
 get this pulled into Django. Isn't here somebody willing to take a look at
 this?

 PR is at https://github.com/django/django/pull/5108

>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> 

Re: [admin] submit_row template tag reusability issue

[Tim Graham]

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 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 
> ,
>  
> you will notice the original view context is not passed entirely to the 
> return statement. A new ctx dictionary is created and filled only with a 
> smaller subset of key/value pairs.
>
> I took a quick look at other template tags and I noticed they return the 
> entire context and not a stripped version of it.
>
> I would prefer submit_row to behave in the same way as the other 
> templatetags so I wouldn't have to duplicate its code to add new context 
> values to it.
> If there's consensus on this issue I can create a ticket and send a pull 
> request, let me know.
>
> Federico
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bbb82460-8a55-47ff-8e7f-acfc063f6cf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Markus Holtermann]

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 their 
accuracy or correctness, less for being up to date.

/Markus

On Monday, February 1, 2016 at 10:06:23 PM UTC+11, Federico Capoano wrote:
>
> 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 ecosystem.
>
> Federico
>
>
> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>>
>> 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-inventing :-)
>> }}}
>>
>>
>> {{{
>> sergei-maertens
>>
>> Resolution set to invalid
>> Status changed from new to closed
>>
>> I don't think the docs are the appropriate place to point out 
>> alternatives. I feel if Django starts going down that road, then you should 
>> do the same not only for pagination, but for forms, views, other db 
>> adapters, other template engines... I think it's a slippery slope.
>>
>> While I think that djangopackages.com is a great resource, I'm not sure 
>> if it (and no other resources) should be 'officially endorsed' by Django in 
>> the docs.
>> }}}
>>
>> I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
>> love to program. But time have
>> changed. There are a lot of great re-usable apps and libraries and 
>> programmers who wants to
>> get things done use them.
>>
>> What do you think for *this* issue: the docs for pagination should point 
>> to the comparison grid or not?
>>
>> Regards,
>>   Thomas Güttler
>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/acce712f-38d8-4813-ac86-bb7c00b85876%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[admin] submit_row template tag reusability issue

[Federico Capoano]

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 
,
 
you will notice the original view context is not passed entirely to the 
return statement. A new ctx dictionary is created and filled only with a 
smaller subset of key/value pairs.

I took a quick look at other template tags and I noticed they return the 
entire context and not a stripped version of it.

I would prefer submit_row to behave in the same way as the other 
templatetags so I wouldn't have to duplicate its code to add new context 
values to it.
If there's consensus on this issue I can create a ticket and send a pull 
request, let me know.

Federico

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8172f221-a312-4cae-b8ee-fd2e9f971b7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Federico Capoano]

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 ecosystem.

Federico


On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>
> 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-inventing :-)
> }}}
>
>
> {{{
> sergei-maertens
>
> Resolution set to invalid
> Status changed from new to closed
>
> I don't think the docs are the appropriate place to point out 
> alternatives. I feel if Django starts going down that road, then you should 
> do the same not only for pagination, but for forms, views, other db 
> adapters, other template engines... I think it's a slippery slope.
>
> While I think that djangopackages.com is a great resource, I'm not sure 
> if it (and no other resources) should be 'officially endorsed' by Django in 
> the docs.
> }}}
>
> I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
> love to program. But time have
> changed. There are a lot of great re-usable apps and libraries and 
> programmers who wants to
> get things done use them.
>
> What do you think for *this* issue: the docs for pagination should point 
> to the comparison grid or not?
>
> Regards,
>   Thomas Güttler
>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/47c444a6-d524-415f-b352-9cba2c4dffe4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[guettli]

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-inventing :-)
}}}


{{{
sergei-maertens

Resolution set to invalid
Status changed from new to closed

I don't think the docs are the appropriate place to point out alternatives. 
I feel if Django starts going down that road, then you should do the same 
not only for pagination, but for forms, views, other db adapters, other 
template engines... I think it's a slippery slope.

While I think that djangopackages.com is a great resource, I'm not sure if 
it (and no other resources) should be 'officially endorsed' by Django in 
the docs.
}}}

I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
love to program. But time have
changed. There are a lot of great re-usable apps and libraries and 
programmers who wants to
get things done use them.

What do you think for *this* issue: the docs for pagination should point to 
the comparison grid or not?

Regards,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ef2de7e2-d122-45f4-80d8-888a27722123%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Aymeric Augustin]

> 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 the awkward “ignore what the field says” query parameter
- trying not to provide separate APIs for insert and update behavior
- improving the save(update_fields=…) API to support inserts as well as updates

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FB10BF37-E6DD-48DD-AA40-ED0B18AE8DD8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.