Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

Hi Kunal, welcome to the Django community! django-pyodbc-azure is the best 
maintained SQL Server engine I've found, and it typically gets updated a 
little more quickly than this. However, Michaya who maintains the package 
has been extremely busy lately, and said it will take him a few more weeks 
to get it done. If you're starting a new project, could you develop on 
SQLite for now and then swap in django-pyodbc-azure when it is ready?

Regards,

Tim

On Thursday, January 18, 2018 at 8:39:42 AM UTC-5, 
kunal...@williamoneilindia.com wrote:
>
> Hi,
>
> I am new to Django, but planning to use Django 2.0 for my newest project. 
> I am using MSSQL db and hence facing issues with it.
>
> Anyone working on getting an MSSQL backend that works with Django 2.0? 
> (Couldn't find one that's up to date including django-pyodbc-azure).
>
>>
>>>

-- 
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/da8052d9-9d3e-4ffd-8432-2b0970226df4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

Aymeric,

If one doesn’t have time to read 21 emails, then should also not have time
to judge them.

Regards,
On Fri, Jan 19, 2018 at 2:33 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> 2018-01-19 17:54 GMT+01:00 Mehmet Dogan :
>
>> I propose throwing out the proposed behavior as Option B, and see what
>> happens.
>>
>
> "Make changes and see what happens" doesn't sound like the way Django is
> maintained in general.
>
> Unfortunately I don't have enough motivation to go through the 21 emails
> you sent over the last week so I can't offer more constructive advice.
>
> Keep in mind that each email to this list is sent to thousands of people.
> You'll get more help if you demonstrate respect for other people's time.
>
> Thanks for your understanding!
>
> --
> Aymeric.
>
> --
> 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/MLWfvPPVwDk/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/CANE-7mViGxVs%3DvP3-%2BkZxuHyuNSHeAaU5Pfg2Ts7Z957rFmK8g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAFdefwMtPs2K%3DRXAvbdBViQvEXupEbZyt%3D-pADsV7GGj%3DFXLRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: About #8500 and #27728

[Raffaele Salmaso]

Hi all,
as these PR have merge conflicts that need to be resolved, and it takes
time to keep that ready to merge, I would be glad to know if continue to
work on them (and how to get them merged) or just drop them and carry on.

Thanks

On Tue, Sep 5, 2017 at 10:57 AM, Raffaele Salmaso 
wrote:

> Hi all,
> I'm working to ticket #8500 and #27728 to improve a bit the admin, and
> being asked to ask to django-developers about some decision.
>
> In ticket #8500 I've used a LazyObject to defer the the real
> django.contrib.admin.sites.site instantiation, so admin.site is always
> the custom one.
> The first approach was simpler, with a setting. But as Tim pointed out it
> doesn't need to be a setting, so I rewrote to be a custom field for
> (Simple)AdminConfig (and django itself doesn't need to know it existence)
>
> Currently I'm monkey patching in my custom admin setup (
> https://bitbucket.org/rsalmaso/django-fluo is my own utility library)
>
> > class FluoAdminConfig(AdminConfig):
> > default_site = "fluo.admin.sites.AdminSite"
> >
> > def ready(self):
> > self.override_admin_site()
> > super().ready()
> >
> > def override_admin_site(self):
> > from django.contrib import admin as django_admin
> > from django.contrib.admin import sites as django_sites
> > from fluo import admin as fluo_admin
> > from fluo.admin.sites import DefaultAdminSite
> >
> > site = DefaultAdminSite()
>
> where the DefaultAdminSite is the same as in PR
> > class DefaultAdminSite(LazyObject):
> > def _setup(self):
> > AdminSiteClass = import_string(apps.get_app_
> config('admin').default_site)
> > self._wrapped = AdminSiteClass()
>
>
> I think it is a better approach than the Jannis' one (
> https://code.djangoproject.com/attachment/ticket/8500/8500.1.diff), as
> Adam claims it is simpler, because
> - it doesn't require to rewrite your admin.py to add an helper function in
> admin.py
> > def register(site):
> > site.register(...)
> - it works with all current third party modules (so don't have to add a
> custom adapter in my own project)
> - can use the @admin.register() decorator as is
>
> Currently all my projects use this approach, and I'm really happy because
> I find no problem with 3rd apps, they always use my custom instance, and
> don't have two different site.
>
> In ticket #27728 I've rewrite all include template tags (submit_row,
> pagination, admin_actions, search_form, date_hierarchy, result_list,
> prepopulated_fields_js, object_tools) to be overridable by the "standard"
> admin pattern (["admin/app_label/app_model/template_name",
> "admin/app_label/template_name", "admin/template_name"]).
> This patch solves even the tickets #11974, #12566, #18957, #19235, #26763.
> Choose to patch all include tags because:
> - I have a project where I override all of them (!)
> - they are all the same implementation, so easy to replicate
>
> The approach is to create a custom InclusionAdminNode, which handle all
> common task to split the include parameters, select the correct template
> and wrapping the original tag function (which are never changed).
>
> Hope this clears all intentions and have them in django 2.0 :)
>
> --
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>



-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4JvtuEGE4kx-%2BPaAzht%2BMdGa2_w2mgj-noMqBHzDntw2Ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Aymeric Augustin]

2018-01-19 17:54 GMT+01:00 Mehmet Dogan :

> I propose throwing out the proposed behavior as Option B, and see what
> happens.
>

"Make changes and see what happens" doesn't sound like the way Django is
maintained in general.

Unfortunately I don't have enough motivation to go through the 21 emails
you sent over the last week so I can't offer more constructive advice.

Keep in mind that each email to this list is sent to thousands of people.
You'll get more help if you demonstrate respect for other people's time.

Thanks for your understanding!

-- 
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/CANE-7mViGxVs%3DvP3-%2BkZxuHyuNSHeAaU5Pfg2Ts7Z957rFmK8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Adding a bulk_save method to models

[Tom Forbes]

Hello all,

I’d love for some feedback on an idea I’ve been mulling around lately,
namely adding a bulk_save method to Dango.

A somewhat common pattern for some applications is to loop over a list of
models, set an attribute and call save on them. This unfortunately can
issue a lot of database queries which can be a significant slowdown. You
can work around this by using ‘.update()’ in some cases, but not all.

It seems it would be possible to use a CASE statement in SQL to handle
bulk-updating many rows with differing values. For example:

SomeModel.object.filter(id__in=[1,2]).update(
some_field=Case(
When(id=1, then=Value('Field value for ID=1')),
When(id=2, then=Value('Field value for ID=2'))
)
)

I’ve made a ticket for this here:
https://code.djangoproject.com/ticket/29037

I managed to get a 70x performance increase using this technique on a
fairly large table, and it seems it could be applicable to many projects
just like bulk_create.

The downsides to this is that it can produce very large SQL statements when
updating many rows (I had MySQL complain about a 10MB statement once), but
this can be overcome with batching and other optimisations (i.e the same
values can use WHEN id IN (x, y, z) rather than 3 individual WHEN
statements).

I’m imagining an API very similar to bulk_create, but spend any time on a
patch I thought I would ask if anyone have any feedback on this suggestion.
Would this be a good addition to Dango?

-- 
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/CAFNZOJOmmRDzZv9jMDxnp3-Wp%3Dg5F1dR_Gga3d51kARKGbrrzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

Hey Carlton,

 

I think everybody said what they would. What do you say? 

 

I propose throwing out the proposed behavior as Option B, and see what 
happens. Something along these lines:

 

*class *ModelBackendIgnoreObject(ModelBackend):

*def *get_user_permissions(self, user_obj, obj=*None*):

*if *obj *is None*:

obj = 
*"NOT_NONE"
*super().get_user_permissions(user_obj, obj)



*def *get_group_permissions(self, user_obj, obj=*None*):

*if *obj *is None*:

obj = 
*"NOT_NONE"
*super().get_group_permissions(user_obj, obj)



*def *get_all_permissions(self, user_obj, obj=*None*):

*if *obj *is None*:

obj = 
*"NOT_NONE"
*super().get_all_permissions(user_obj, obj)



*def *has_perm(self, user_obj, perm, obj=*None*):

*if *obj *is None*:

obj = 
*"NOT_NONE"
*super().has_perm(user_obj, obj)



By the time, I am getting acclimated to the idea of "do not fix" but I think 
this is good for new comers to the framework, and general population. 

-- 
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/6d05b14d-dd56-4030-b9f9-15c8c8d8439a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Authorization Backend Proposals for Utility Methods

[Mehmet Dogan]

Hello All,

I would like to get your opinions on what seemed to me useful additions to 
the `auth.backends.ModelBackend`. These are polled by the `auth.models` and 
not every backend has to implement them.

1) clear_cache()

default backend caches permissions at `user._user_perm_cache`, 
`user._group_perm_cache` and cumulatively: `user._perm_cache`. Most other 
backends also do things similar. If an app uses 2-3 backends, resetting 
cache after adding a permission becomes a chore. 

2) has_perms_any ()

we have one (has_perms) that requires *all* permissions given, why not *any*? 
If this makes it, the other may also be renamed to has_perms_all ()

3) get_permisson_objects ()

guardian has something like this, and i think it would be nice if the 
default backend also provided similar. if it did, it would be either 
Model.objects.all() or Model.objects.none(); does not look much useful, 
however if one uses say 3 backends, it does seem useful. If implemented, 
due to diverse nature of backends it may be hard, if at all possible, to 
implement lazy loading, thus, may incur performance costs. If you think 
this is useful, please also share if you have design ideas. 

4) get_backends ()

this is not really a utility method, but a move request. It is currently 
under auth.__init__(); I think if it was moved to somewhere that could be 
overrided, it would allow one to pick and choose backends locally from the 
code if needed. 

Regards,

Mehmet

-- 
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/0ca47426-e700-473e-ba49-5eb748210a38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report — January 19, 2018

[Carlton Gibson]

Hi All. 

This week I reviewed patches on: 

https://code.djangoproject.com/ticket/24747 -- Allowed transforms in 
order_by()
https://code.djangoproject.com/ticket/28977 -- Change Local Memory Cache to 
use LRU
https://code.djangoproject.com/ticket/28881 -- Documented that 
CommonPasswordValidator assumes lowercase
https://code.djangoproject.com/ticket/28403 -- Improve the example for 
FORMAT_MODULE_PATH and add missing formats
https://code.djangoproject.com/ticket/28838 -- annotations + 
base_manager_name + instance.save() raises exception
https://code.djangoproject.com/ticket/20218 -- Default authorization 
backend returns False when queried for object level permissions
https://code.djangoproject.com/ticket/28643 -- Complete the ORM Function 
Library
https://code.djangoproject.com/ticket/25790 -- Add a way to disable column 
sorting in the admin
https://code.djangoproject.com/ticket/28990 -- Added support for Hash and 
SP-Gist indexes; BrinIndex autosummarize parameter
https://code.djangoproject.com/ticket/28887
https://code.djangoproject.com/ticket/26974
https://code.djangoproject.com/ticket/28917 -- Remove paginator's unordered 
queryset warning for a .none() queryset

Kind Regards,

Carlton

-- 
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/680acc99-9857-4e13-9a4d-13f43e6152f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.