Re: Override the default form field for a model field

[Johannes Hoppe]

Hi Tim, and I guess that's you James?

Thanks for pointing me towards this discussion. Tho I do like the idea for 
the sake of `django-select2`, I think it's a bad idea for Django.
I don't think that `django.db` should be even aware of `django.forms`. I 
don't even like the current implementation that much. I don't think
that a db field needs to define it's form representation. It should be the 
other way around from my opinion. With single page apps and DRF on the rise,
forms are becoming less of a core feature than they used to.
With that perspective in mind, I think it's a bad idea to introduce even 
more cross dependencies.

@James: If this is only about widget definition in ModelForms, why not just 
use the Meta class?

Cheers,
Joe

On Monday, March 7, 2016 at 8:36:10 PM UTC+1, is_null wrote:
>
> Thanks Tim. Something like that would work, perhaps the first step 
> would be to make modelfield.formfield a bit more configurable ? 
>
> Currently, the default form field class for a model field is hardcoded 
> in the model field's formfield() method, ie: 
>
> https://github.com/django/django/blob/master/django/db/models/fields/related.py#L945
>  
>
> Changing this to an attribute allows to replace it in an 
> AppConfig.ready() method as such: 
>
> class TestApp(AppConfig): 
> name = 'select2_one_to_one' 
>
> def ready(self): 
> model = self.get_model('TestModel') 
> # Perhaps that's the kind of nice place to override this 
> kind of things 
> model._meta.get_field('test').formfield_defaults['widget'] 
> = forms.RadioSelect 
> # django-autocomplete-light users would execute something 
> like: 
> model._meta.get_field('test').formfield_defaults['widget'] 
> = autocomplete.Select2(url='my_autocomplete_url') 
>
> This also allows to change it when defining the field: 
>
> class TestModel(models.Model): 
> name = models.CharField(max_length=200) 
>
> test = models.OneToOneField( 
> 'self', 
> null=True, 
> blank=True, 
> related_name='related_test_models', 
> # This seems like it would always be useful 
> formfield_defaults={ 
> 'widget': forms.RadioSelect 
> } 
> ) 
>
> I checked that this changed rendering in the admin, and it felt pretty 
> awesome I recon, to see my override in the default form and inline 
> model forms too. 
>
> Here's what the poc patch looks like for ForeignKey (3 additions and 1 
> deletion, works on OneToOne field too): 
>
>
> https://github.com/jpic/django/commit/d102f362f3c1ceaf2d5224d71f788c0821a481ae
>  
>
> Of course, that works when the model field already supports a form 
> field. It doesn't solve the problem with virtual fields that don't 
> have a formfield() method like GenericForeignKey, where an app would 
> like to be able to provide a formfield() as well as logic for 
> modelfield.{value_from_object,save_form_data}(). Perhaps that's 
> something we could deal with later *if* we decide to deal with it ? 
>
> Meanwhile, could we perhaps start working on a consistent way to 
> configure formfield() in Django ? That doesn't solve all the use cases 
> I mentioned, but perhaps it would be a nice step forward. 
>

-- 
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/4762ff24-8f4e-4a9d-9ea4-160764b8622a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

Hi !

Currently, by default, django's ModelForm uses form fields which are
known to be compatible for the modelfield.

By "compatible", I mean that it works when the ModelForm calls:

- ModelField.value_from_object() to get the initial formfield value
for the model's field, via model_to_dict:
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L101-L107
- ModelField.save_form_data() to save the form field's value, via
construct_instance and save_m2m:
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L47-L63
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L427-L446

To get the form field that's compatible with both ModelField methods,
it calls ModelField.formfield(), via fields_for_models, again in
django.forms.models:
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L178

There's got to be somewhere to couple both the db field and the form
fields, and that seems to be in model fields. Note that ModelForm is
not in django.forms, but in django.forms.models. That module
encapsulates all coupling between django.forms and django.db.models.
Perhaps it would have been a bit more intuitive to have such a set of
modules: django.db, django.forms, django.models, django.models_forms.
That would be moving code around, but the code wouldn't change and the
result would be the same - so I figured when I gave it a try ;)

Anyway, I opened this topic because I thought it would be cool if we
could change the **default** formfield that is generated by
ModelForms. I know there are means to override the defaults, but that
means a lot of boilerplate code to override the form class every where
(views, admin, admin inlines ...). This feature is heavily used in DAL
v2 but really has nothing to do in an autocomplete app. It would be
nice if we could change the **default** formfields used by ModelForm,
from it's current logic "known-to-be-compatible", to an enhanced logic
"best for project". "Best for project" is defined by the
INSTALLED_APPS and the configuration these apps have. It would be
really cool to have these features in Django so that every app could
benefit from it because it would make form configuration a lot more
DRY. Currently in Django, even if a project defines its own ModelFormS
with their overrides (for every model), or even a custom
ModelFormMetaclass, users have to override everything in Django to use
that. This proposal is about allowing to change defaults.

I found two ways of achieving this, perhaps there are more:

- make ModelFormMetaclass more configurable (a PoC
https://github.com/jpic/xmodelform/blob/7de16ca1826c1bee91d9a5b616b78d3dff357fa4/xmodelform/forms.py#L118-L170
), but it's a bit more "fuzzy" to know if a form field is "compatible"
(as defined above) with the model field, unless we permit form fields
to override value_from_object() and save_form_data() which are
currently in model fields. Note that save_form_data() can be called
before or after form.save(), depending on wether it is a (many to many
field, virtual field) or not (
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L438
). Also, we'd need a setting to allow a project to change what is the
default modelform class or metaclass it would use in django factories.

- add instance attributes for model fields to override the currently
hard coded defaults in formfield().

Unless we can get more of the community involved in this, is seems
more sane to go for the second option. The risk of doing something
wrong(tm) when changing hard coded defaults to attributes is None as
far as I understand.

Are there any better way to override **default** form fields generated
for models at the project-level ?

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

Re: Override the default form field for a model field

[Johannes Hoppe]

We'll you can change the `default` form Field using
`django.db.models.Field.formfield`.

But that is actually the thing I don't like I think this needs to go: https://
github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/
db/models/fields/__init__.py#L869-L905

  

But at the end, I don't have a particular pain with all that. You can easily
write your own model form, that changes the behavior. If you feel like
changing it, go ahead, but I would welcome a removing the cross dependency.

> On Mar 9 2016, at 2:34 pm, James Pic  wrote:  

>

> Hi !

>

> Currently, by default, django's ModelForm uses form fields which are  
known to be compatible for the modelfield.

>

> By "compatible", I mean that it works when the ModelForm calls:

>

> \- ModelField.value_from_object() to get the initial formfield value  
for the model's field, via model_to_dict:  
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7
/django/forms/models.py#L101-L107  
\- ModelField.save_form_data() to save the form field's value, via  
construct_instance and save_m2m:  
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7
/django/forms/models.py#L47-L63  
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7
/django/forms/models.py#L427-L446

>

> To get the form field that's compatible with both ModelField methods,  
it calls ModelField.formfield(), via fields_for_models, again in  
django.forms.models:  
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7
/django/forms/models.py#L178

>

> There's got to be somewhere to couple both the db field and the form  
fields, and that seems to be in model fields. Note that ModelForm is  
not in django.forms, but in django.forms.models. That module  
encapsulates all coupling between django.forms and django.db.models.  
Perhaps it would have been a bit more intuitive to have such a set of  
modules: django.db, django.forms, django.models, django.models_forms.  
That would be moving code around, but the code wouldn't change and the  
result would be the same - so I figured when I gave it a try ;)

>

> Anyway, I opened this topic because I thought it would be cool if we  
could change the **default** formfield that is generated by  
ModelForms. I know there are means to override the defaults, but that  
means a lot of boilerplate code to override the form class every where  
(views, admin, admin inlines ...). This feature is heavily used in DAL  
v2 but really has nothing to do in an autocomplete app. It would be  
nice if we could change the **default** formfields used by ModelForm,  
from it's current logic "known-to-be-compatible", to an enhanced logic  
"best for project". "Best for project" is defined by the  
INSTALLED_APPS and the configuration these apps have. It would be  
really cool to have these features in Django so that every app could  
benefit from it because it would make form configuration a lot more  
DRY. Currently in Django, even if a project defines its own ModelFormS  
with their overrides (for every model), or even a custom  
ModelFormMetaclass, users have to override everything in Django to use  
that. This proposal is about allowing to change defaults.

>

> I found two ways of achieving this, perhaps there are more:

>

> \- make ModelFormMetaclass more configurable (a PoC  
https://github.com/jpic/xmodelform/blob/7de16ca1826c1bee91d9a5b616b78d3dff357f
a4/xmodelform/forms.py#L118-L170  
), but it's a bit more "fuzzy" to know if a form field is "compatible"  
(as defined above) with the model field, unless we permit form fields  
to override value_from_object() and save_form_data() which are  
currently in model fields. Note that save_form_data() can be called  
before or after form.save(), depending on wether it is a (many to many  
field, virtual field) or not (  
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7
/django/forms/models.py#L438  
). Also, we'd need a setting to allow a project to change what is the  
default modelform class or metaclass it would use in django factories.

>

> \- add instance attributes for model fields to override the currently  
hard coded defaults in formfield().

>

> Unless we can get more of the community involved in this, is seems  
more sane to go for the second option. The risk of doing something  
wrong(tm) when changing hard coded defaults to attributes is None as  
far as I understand.

>

> Are there any better way to override **default** form fields generated  
for models at the project-level ?

>

> \--  
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/zG-JvS_opi4/unsubscribe.  
To unsubscribe from this group and all its topics, send an email to django-
developers

Re: Override the default form field for a model field

[James Pic]

On Wed, Mar 9, 2016 at 3:09 PM, Johannes Hoppe  wrote:
> We'll you can change the `default` form Field using
> `django.db.models.Field.formfield`.

Do you mean that, for example, an app like django-select2 could
provide the following model fields ?

- Select2WidgetForeignKey,
- Select2WidgetOneToOneField,
- Select2MultipleWidgetManyToManyField,
- HeavySelect2WidgetForeignKey,
- HeavySelect2WidgetOneToOneField,
- HeavySelect2MultipleWidgetManyToManyField

Also, wouldn't that require overriding the complete model class to
change the default widget for an external app ?

Also, would it be possible to conditionally enable Select2 widgets
depending whether select2 is in INSTALLED_APPS without changing the
model class ?

Or perhaps everybody would benefit from changing these hardcoded
values into attributes ?

> But that is actually the thing I don't like I think this needs to go:
> https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/db/models/fields/__init__.py#L869-L905

If that goes, so should save_form_data and value_from_object, that's
the first option I was talking about. I think we can still do that
later. Changing the hardcoded defaults into instance attributes would
still be useful when we do that.

>
> But at the end, I don't have a particular pain with all that. You can easily
> write your own model form, that changes the behavior. If you feel like
> changing it, go ahead, but I would welcome a removing the cross dependency.

There's got to be code that couples db fields and form fields, perhaps
it would help to move it around, but we'll also have to change it.

Again, I think both solutions are good here: we don't have to choose
one or another. When have the opportunity to do one before the other,
which benefits to django's stability because moving .formfield()
outside the model field is going to cause a lot of BC breaks in apps
and projects.

Thanks for sharing a bit of your time !

Best

-- 
http://yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

-- 
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/CALC3KadmQM6TmKsabD3yf5_r5cqa0JiEe%2BHZph8reTRe0iO%2BCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Summer of Code Idea: Class-based [Object] Permissions

[Tim Graham]

1. Not sure, but it seems similar to the access mixins introduced in Django 
1.9: 
https://docs.djangoproject.com/en/1.9/releases/1.9/#permission-mixins-for-class-based-views
2. Any large feature that is twelve weeks worth of work for which you can 
find a mentor for should be okay. You should include a timeline of tasks in 
your proposal.

On Monday, March 7, 2016 at 10:33:34 AM UTC-5, Connor Boyle wrote:
>
> As I understand, some parts of Django-Rest-Framework 
> 
>  are 
> being considered for integration into Django (please correct me if I'm 
> mistaken). I'm not sure what specifically core plans to bring in, but in my 
> opinion the feature that core Django needs the most from DRF has no direct 
> connection to APIs or JSON: it's the extremely well-designed class-based 
> permissions 
> system .
>
> For those who aren't familiar, the bottom line is that it's a system that 
> allows the developer to run their own arbitrary code (in a clean, DRY, and 
> readable way) to determine whether or not to return a 403 given a 
> particular request and view. Any class-based view (with the provided mixin) 
> can be assigned a tuple of permissions to check. In other words, it is the 
> answer to our prayers.
>
> Example:
>
> MyApp/permissions.py: 
> from rest_framework import permissions
>
>
> class IsFromTexas(permissions.BasePermission):
> '''Only allow users from Texas.
> '''
> def has_permission(self, request, view):
> return request.user.state == 'TEXAS'
>
> MyApp/views.py:
> from MyApp.permissions import IsFromTexas
> # Other imports
>
> class MapOfTexasView(ClassPermissionsMixin, TemplateView):  # 
> ClassPermissionsMixin does not actually exist yet
> '''Return a map of Texas. Only allow users from Texas.
> '''
> permission_classes = (IsFromTexas,)
> template_name = 'map_of_texas.html'
>
> Checking against an object is trivial, and DRF's implementation makes it 
> even easier and cleaner by providing a has_object_permission() method that 
> gets passed the result of the view's get_object() if it has one (and makes 
> it so the developer doesn't have to worry about accidentally calling 
> get_object() multiple times).
>
> I'm considering applying for Summer of Code with this (adding class-based 
> permissions to Django) as the subject of my proposal. I would also add some 
> features that DRF is missing, such as permission-checking on QuerySets, 
> adding class-based permission checking to default class-based views, and 
> dividing permissions into read and write.
>
> A few questions for anyone who can answer them:
>
> 1. Is there any chance of getting this accepted as a feature? (through 
> Summer of Code or otherwise)
> 2. Is this appropriate in scope and significance for a Summer of Code 
> project? I'm guessing it would be relatively little actual code, but could 
> potentially be a fundamental part of a huge number of projects made with 
> Django.
> 3. I suspect that if this were to be added to Django core, we'd want to 
> use a name other than 'permissions' given that Django already has its own 
> permissions system that uses that name. How does 'authorizations' sound?
>
>
> Connor Boyle
> Macalester College
>

-- 
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/89a91ced-5ce2-412a-ac27-267ecdb7107c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[Johannes Hoppe]

  
Regarding django-select2:  
  
I don’t want to provide fields at this point. Django has the concept of
widgets, and that is all I need for select2.  
  
You could overwrite the widget for all forms with a template processor, but
why? You’d need to know which db columns you need too search to filter the
query set, but in some cases you use a full text index or even elastic search.  
  
Besides, django-select2 started with fields and we moved it to widgets, just
to reduce the code base and complexity. After all, you need to maintain all
that code.  
  
I wouldn’t introduce too much magic (pep20). We made the field definition in
ModelForms mandatory and a lot of other “assumptions” have been deleted in
recent releases.  
  

> On Mar 9 2016, at 3:26 pm, James Pic  wrote:  

>

> On Wed, Mar 9, 2016 at 3:09 PM, Johannes Hoppe
 wrote:  
> We'll you can change the `default` form Field using  
> `django.db.models.Field.formfield`.

>

> Do you mean that, for example, an app like django-select2 could  
provide the following model fields ?

>

> \- Select2WidgetForeignKey,  
\- Select2WidgetOneToOneField,  
\- Select2MultipleWidgetManyToManyField,  
\- HeavySelect2WidgetForeignKey,  
\- HeavySelect2WidgetOneToOneField,  
\- HeavySelect2MultipleWidgetManyToManyField

>

> Also, wouldn't that require overriding the complete model class to  
change the default widget for an external app ?

>

> Also, would it be possible to conditionally enable Select2 widgets  
depending whether select2 is in INSTALLED_APPS without changing the  
model class ?

>

> Or perhaps everybody would benefit from changing these hardcoded  
values into attributes ?

>

> > But that is actually the thing I don't like I think this needs to go:  
> https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae62879
2c8f7/django/db/models/fields/__init__.py#L869-L905

>

> If that goes, so should save_form_data and value_from_object, that's  
the first option I was talking about. I think we can still do that  
later. Changing the hardcoded defaults into instance attributes would  
still be useful when we do that.

>

> >  
> But at the end, I don't have a particular pain with all that. You can
easily  
> write your own model form, that changes the behavior. If you feel like  
> changing it, go ahead, but I would welcome a removing the cross
dependency.

>

> There's got to be code that couples db fields and form fields, perhaps  
it would help to move it around, but we'll also have to change it.

>

> Again, I think both solutions are good here: we don't have to choose  
one or another. When have the opportunity to do one before the other,  
which benefits to django's stability because moving .formfield()  
outside the model field is going to cause a lot of BC breaks in apps  
and projects.

>

> Thanks for sharing a bit of your time !

>

> Best

>

> \--  
  
Customer is king - Le client est roi - El cliente es rey.

>

> \--  
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/zG-JvS_opi4/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/CALC3KadmQM6TmKsabD3yf5_r5cqa0JiEe%2BHZph8reTRe0iO%2BCg%40m
ail.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/a2cempdctyubtm9n4v815dwh1-0%40mailer.nylas.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

I just meant that currently, if a user wants to make Select2 the
default widget for a model field, it is necessary to subclass the
modelfield class and override the model field's formfield() method
just to change the default widget it uses, sorry if it wasn't clear !

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

Re: Override the default form field for a model field

[Johannes Hoppe]

I got that, but you can't just make it your default widget, it will always
require more information. And I don't really like "defaults", again pep20.  

  

I currently don't have any need for action, therefore I won't do anything. If
you want to make a draft on how to refactor it, I'm happy to review it.

> On Mar 9 2016, at 6:49 pm, James Pic  wrote:  

>

> I just meant that currently, if a user wants to make Select2 the  
default widget for a model field, it is necessary to subclass the  
modelfield class and override the model field's formfield() method  
just to change the default widget it uses, sorry if it wasn't clear !

>

> \--  
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/zG-JvS_opi4/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/CALC3Kaet9-Fy7BF64Fgtjh3MBz9EA7DR67FUkzhdS2HGg4821g%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/diyl3ltvflu4omhaebrin5lf9-0%40mailer.nylas.com.
For more options, visit https://groups.google.com/d/optout.

[ GSoC2016 ] Integration of django and angular2

[Вадим Горбачев]

Hello.

I am a student of the St. Petersburg State Polytechnical University.
But I am also a web-developer 
 .

Now the problem of integration of django and angular2 is very interesting 
to me.
And I want to submit the application in this direction.

*Reason:*
 There are many decisions on the basis of django + angularJS, 
 and it is good to aggregate this knowledge that will help many developers 
not to step on the same rake.
 Very big contribution to the solution of this problem can be found here 
. 

 But with an exit of ECMAscript6 and angular2, there is a wish to pass to 
them somewhat quicker.
 ECMAscript6 is awesome!

*Question:*
 Whether there will be interestingly this task to community?
 Or to look for a work subject more approximate to the offered list?

thanks in advance!

-- 
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/e83d785a-170c-48c9-9364-2edcdf18599b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

 Hi Josh and Anssi,

 Thanks for the feedback. Much appreciated.


> - The earlier part of your proposal seems to focus on allowing postgres 
> users to define more complex indexes that they previously haven't been able 
> to use. Oracle is then highlighted also for allowing functional indexes. I 
> think one of the biggest "why's" of this project is to allow users to 
> define custom indexes. It doesn't matter what kind of index. They get 
> access to the stuff that creates them. That should be highlighted before 
> all else.
>

Looks like with all the new ideas that could be incorporated into this 
proposal, the main point of motivation for this concept got a bit hazy in 
the proposal. I'll rectify that.
 

>
> - Should the type of index (BTree, Spatial, etc) be an index type in and 
> of itself, or should it be a property of a specific index? My knowledge 
> here is limited, so I'm not sure if there are certain constraints on which 
> kind of indexes can use spatial/btree/partial storage types. If certain 
> index types are very heavily restricted, then it probably makes sense to 
> highlight them (as you've done) as a top level class rather than an 
> attribute of indexes in general. If most indexes can be arranged with 
> different storage types though, it'd probably make more sense to expose 
> that functionality as an attribute of all indexes.
>

Seeing the syntax for creating indexes on various types of databases, I 
think it would be possible to make a generic Index class (type of index 
{Spatial, Unique} and method {BTree, Hash} being properties of this class). 
There are no major restrictions (the biggest I can think of being 
multi-column indexing cannot use Hash or R-tree) on usage of methods by 
different indexes.
But I don't want the user to be hardcoding strings like "hash" in the 
kwargs. Maybe something like Index(['field1', 'field2'], 
method=models.HashIndex) should be good. In that case Hash, BTree won't be 
subclasses of Index.
 

>
> - "Index() subclasses will also have a supports(backend) method which 
> would return True or False depending on whether the backend supports that 
> index type." Backends (operations.py) already supports 
> check_expression_support(self, expression). You can bake index support into 
> these methods from within each backend. Especially helpful for third party 
> backends, as they won't need to monkey patch the index classes. The only 
> issue I can see with reusing check_expression_support is the overhead of 
> all other expressions being checked. I don't think that's a big concern, 
> but it's worth being conscious of.
>

I remember shaib had once raised this concern for third-party backends 
somewhere, don't know how I missed addressing this issue in the proposal.
Anyways, I see and I agree that we can use check_expression_support for 
that. Also regarding the overhead issue mentioned, I think we can make a 
more generic function like check_support (afterall, 
check_expression_support has also evolved from check_aggregate_support) or 
maybe implement some other way. But I don't that would be a big trouble.
 

>
> - "Index classes will take 3 arguments fields, model and name - the later 
> two being optional.". Index classes should accept a list of expressions, 
> not just field names. This will allow trivial support of functional indexes 
> without a specific functional index class. You'll also benefit from 
> existing expression subclasses which process field names as F() 
> expressions. F() expressions may have to be changed (or a new concept 
> introduced) which can resolve the field, but doesn't try to do any joining.
>

I had left this part solely to functional indexes, because I think it would 
be better to keep the basic class simple otherwise making even the basic 
Index class work would require some fiddling with expressions.
One thing I can do is tweak Index class back again once I am successfully 
able to make functional indexes work. Maybe I should reword this point in 
my proposal to make it clear.
Perhaps I would be able to answer this more clearly, when I have a concrete 
vision (or at least a trail) on how to use F() expressions in Index class.
 

>
> Once the index is added to a model, the model can inject itself into the 
> index, or the schema editor can use the originating model to get data it 
> needs. No need to pass the model into the index type I think. Regarding the 
> name, I'm unsure if I prefer a name=Index() or an Index(name='') approach. 
> It'd be good to see that choice in your proposal with a couple of pros and 
> cons.
>

Well, since we are defining these indexes in a list (to be stored in 
Meta.indexes) I would go with the Index(name='') approach.
 

>
> 1) I don't think it's necessary to have an IndexTogether type. 
> Index('field_a', 'field_b') should be sufficient I think. If it's not 
> sufficient, call out why. I'm also in favour of translating any 
> index_together definitions into appropriate Index types. Then

Re: TransactionManagementError is raised when autocommit …

[Aymeric Augustin]

Hi Tore,

I’ve been meaning to check whether your use case was supported, because it 
should be. I’m sorry, it took me a few days to find the time to investigate.

While I was testing, I produced an exception which looks similar to the problem 
you originally reported: https://code.djangoproject.com/ticket/26340.

Specifically, could you try adding `self.needs_rollback = False` at the bottom 
of the `BaseDatabaseWrapper.rollback()` and tell me if that helps?

(Since I don’t remember hearing you mention savepoints, you can probably ignore 
everything I say about savepoints.)



> On 07 Mar 2016, at 12:55, Tore Lundqvist  wrote:
> 
> an example of when it happens is when:
> 
> Starting with auto commit on.
> transaction.set_autocommit(False)
> ... a lot of time passes without the connection being used so it times out
> close_old_connections()

There’s a long discussion of this use case here: 
https://code.djangoproject.com/ticket/21597.

> Now autocommit is on again. I'm not saying that it's a bug, but it's 
> inconvenient.

This surprises me. The connection shouldn’t reopen at all. It should become 
unusable, for the reasons explained in that issue (ticket 21597).

Regardless, at any point in the code where you expect not to use the database 
connection for some time, you should close it explicitly with 
connection.close(). Then you can call set_autocommit(False) when you’re about 
to start using the database connection again.

Since I don’t expect the database timeout to be reached while handling a HTTP 
request, I assume this happens in a long-running management command. You could 
have another settings module just for the purpose of running that command. It 
would be the same as your regular settings module, except it would set the 
AUTOCOMMIT option to False in the database configuration. In that case, you 
wouldn’t need to call set_autocommit(False).



> The problem is that the legacy code uses COMMIT side effects to manage disk 
> writes and avoid deadlocks, securing an adequate transactional integrity is 
> often not an issue.

That’s an interesting way to use transactions, and to be honest, one I never 
imagined ;-)

While I wouldn’t recommend that design for new code, Django shouldn’t prevent 
you from continuing to use it.

Obviously, some other users of Django need transactional integrity. We can’t 
relax that constraint when discussing changes to Django.

> So I'm trying to disable or at least use as little as possible of Djangos 
> transaction management for this code.


After transaction.set_autocommit(False), transaction.commit() and 
transaction.rollback() seem to work fine.

As I pointed out in my previous messages, you have to rollback with 
transaction.atomic() when you’re catching IntegrityError.

I thought you could rollback with transaction.rollback() or 
transaction.savepoint_rollback(). It turns out you also need to call 
transaction.set_rollback(False). Essentially this tells Django “hey, I’m happy 
to continue from this point, just go ahead”.

I think Django could do better. That’s why I filed the issue I mentioned at the 
beginning of this email (ticket 26340).

Given MySQL’s interesting approach to transactional integrity, you can call 
transaction.set_rollback(False) after a query that failed with an 
IntegrityError and keep going.



In case that’s useful, here are some patterns that work currently. A and B are 
two distinct sessions. I’m using session B to check whether the changes from 
session A have been committed.

I have a user model with a unique email field. I used PostgreSQL because I 
don’t have a MySQL instance around. If you’re getting different results on 
MySQL, it’s a bug.

A >>> from django.db import IntegrityError, transaction
A >>> transaction.set_autocommit(False)
A >>> User.objects.create(email='us...@example.com')
A 
A >>> User.objects.create(email='us...@example.com')
A 

B >>> User.objects.filter(email__startswith='user')
B []

A >>> transaction.commit()

B >>> User.objects.filter(email__startswith='user')
B [, ]

A >>> try:
A ... with transaction.atomic():
A ... User.objects.create(email='us...@example.com')
A ... except IntegrityError:
A ... print("duplicate")
A ... 
A 
A >>> try:
A ... with transaction.atomic():
A ... User.objects.create(email='us...@example.com')
A ... except IntegrityError:
A ... print("duplicate")
A ... 
A duplicate
A >>> try:
A ... with transaction.atomic():
A ... User.objects.create(email='us...@example.com')
A ... except IntegrityError:
A ... print("duplicate")
A ... 
A 

B >>> User.objects.filter(email__startswith='user')
B [, ]

A >>> transaction.commit()

B >>> User.objects.filter(email__startswith='user')
B [, , , ]

A >>> User.objects.create(email='us...@example.com')
A 
A >>> User.objects.create(email='us...@example.com')
A 

B >>

Re: [ GSoC2016 ] Integration of django and angular2

[Tim Graham]

I'm not sure what the end product you have in mind would look like, but I 
don't think Django (core) is going to adopt tight integration with any 
JavaScript framework. You pointed to a third-party package... what's the 
problem with it and how would your proposal differ?

On Wednesday, March 9, 2016 at 3:33:49 PM UTC-5, Вадим Горбачев wrote:
>
> Hello.
>
> I am a student of the St. Petersburg State Polytechnical University.
> But I am also a web-developer 
>  .
>
> Now the problem of integration of django and angular2 is very interesting 
> to me.
> And I want to submit the application in this direction.
>
> *Reason:*
>  There are many decisions on the basis of django + angularJS, 
>  and it is good to aggregate this knowledge that will help many developers 
> not to step on the same rake.
>  Very big contribution to the solution of this problem can be found here 
> . 
>
>  But with an exit of ECMAscript6 and angular2, there is a wish to pass to 
> them somewhat quicker.
>  ECMAscript6 is awesome!
>
> *Question:*
>  Whether there will be interestingly this task to community?
>  Or to look for a work subject more approximate to the offered list?
>
> thanks in advance!
>

-- 
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/f4ef5887-3d8b-4c76-8d00-ffdb085df5d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ GSoC2016 ] Integration of django and angular2

[Cristiano Coelho]

In my opinion angular + django + django-rest-framework is a very powerful 
combo, and using django templates mixed with angular (for anything else 
than the index page) is really a bad idea due to templates being very slow 
and rendered by python. Angular must run against a 100% web api with its 
own template framework running everything client side. If I'm not wrong 
django-angular uses this angular + django templates aproach, would the one 
with angular2 be any different?

El miércoles, 9 de marzo de 2016, 17:33:49 (UTC-3), Вадим Горбачев escribió:
>
> Hello.
>
> I am a student of the St. Petersburg State Polytechnical University.
> But I am also a web-developer 
>  .
>
> Now the problem of integration of django and angular2 is very interesting 
> to me.
> And I want to submit the application in this direction.
>
> *Reason:*
>  There are many decisions on the basis of django + angularJS, 
>  and it is good to aggregate this knowledge that will help many developers 
> not to step on the same rake.
>  Very big contribution to the solution of this problem can be found here 
> . 
>
>  But with an exit of ECMAscript6 and angular2, there is a wish to pass to 
> them somewhat quicker.
>  ECMAscript6 is awesome!
>
> *Question:*
>  Whether there will be interestingly this task to community?
>  Or to look for a work subject more approximate to the offered list?
>
> thanks in advance!
>

-- 
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/2428ca85-ebbe-40d2-ac95-edb7a5dca3a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Cristiano Coelho]

"Improve documentation/examples [decrease confusion]: There's already so 
much awesome content out there on getting started with Django (but not many 
are referencing MSSQL as the db of choice or why MSSQL is a great option)."

I wouldn't think of MSSQL as a great option for django at least until it is 
supported natively and not through 3rd party apps which are always behind 
django updates.

El martes, 8 de marzo de 2016, 23:20:58 (UTC-3), Vin Yu escribió:
>
> Hey Tim,
>
> We've gotten lots of questions about the tools when we announced SQL 
> Server on Linux. I am curious; what are the DB management/development tasks 
> that are being performed by your coworkers? What are they using SSMS for? I 
> am interested in learning more. [Perhaps we can follow up by email as this 
> seens off-topic here :) ] 
>
> In terms of strengthening the story for MSSQL-Django, I think there is a 
> little bit of both difficulty and confusion over options; here are some 
> ideas that we are working on and could solve these issues:
>
>- Improve documentation/examples [decrease confusion]: There's already 
>so much awesome content out there on getting started with Django (but not 
>many are referencing MSSQL as the db of choice or why MSSQL is a great 
>option).
>- Improve getting started experience [decrease difficulty]: Getting 
>MSSQL for development (free and easy/fast set up) is hard today;this is on 
>MSFT to improve this experience.
>
> We want to help provide better developer experiences for those who want to 
> create new Django apps + MSSQL databases and if MSSQL were in the core, it 
> would definitely help with that. This would increase usage and is something 
> we are striving to achieve. We will continue to work with the community to 
> make this happen.  
>
> =) , 
> Vin
>
>
> On Tuesday, 8 March 2016 10:13:34 UTC-8, Tim Allen wrote:
>>
>> [slightly off-topic] I'm wondering if this will extend to SQL Server 
>> Management Studio. While I'm mainly a command line basher, many of 
>> coworkers are married to the GUI. I've found SSMS blows the competition out 
>> of the water when it comes to DB management GUIs. I'm wondering if this 
>> means SSMS will run on Linux (or Mac) eventually.
>>
>> This is certainly very big news. I wouldn't be shocked to some day see 
>> Windows itself running on the Linux Kernel.
>>
>> Meet, how can we help strengthen the story for MSSQL-Django? It seems we 
>> have a chicken and egg problem here. A very small amount of Django sites 
>> use SQL Server, but is that because of the difficulty in the available 
>> stack and confusion over options? Would usage increase if provided in core?
>>
>> On Monday, March 7, 2016 at 6:03:29 PM UTC-5, Josh Smeaton wrote:
>>>
>>> Wow, that's really great news! I haven't used mssql for a number of 
>>> years but it was always very nice to work with. Having it available to run 
>>> on linux will make it much easier for the Django community to test against 
>>> mssql, provided we're able to get/develop an appropriate driver and 
>>> backend. 
>>>
>>> Cheers
>>>
>>> On Tuesday, 8 March 2016 09:37:06 UTC+11, Meet Bhagdev wrote:

 Hi all,

 On interacting with several Django developers and committers, one of 
 the questions often came up, can I use SQL Server on non Window OS's? I 
 wanted to share that today Microsoft announced SQL Server availibility on 
 Linux - 
 https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
 . 

 While there is still work needed to strengthen the MSSQL-Django story, 
 we hope this aids more Linux developers to give SQL Server a shot. Let me 
 know of your thoughts and questions :)

 Cheers,
 Meet

 On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>
> Hey Folks, 
>
> My name is Vin and I work with Meet in the Microsoft SQL Server team. 
> Just wanted to let you all know we are still looking into how we can 
> better 
> improve and support MSSQL for the Django framework. We’ll continue to 
> sync 
> with Michael and let you know of any updates soon. 
>
> Christiano and Tim - thanks for sharing your interest and sharing how 
> you are using Django with MSSQL. It's great to learn from your scenarios. 
>
> If you have any concerns, questions or comments feel free to reach out 
> to me at vinsonyu[at]microsoft.com



-- 
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/69f0399b-95a1-46

Re: deprecating the "escape" half of django.utils.safestring (#24046)

[Collin Anderson]

This makes sense to me. mark_for_escaping() seems like a no-op to me.

On Sat, Mar 5, 2016 at 11:16 AM, Tim Graham  wrote:

> Aymeric raised this ticket [0] while working on multiple template engines:
>
>
> "Since any data that isn't explicitly marked as safe must be treated as
> unsafe, I don't understand why we have EscapeData and its subclasses nor
> the mark_for_escaping function. It seems to me that we could keep only
> the "safe" half of django.utils.safestring and deprecate the "escape" half.
> As a matter of fact the "escape" isn't used meaningfully anywhere in
> Django."
>
>
> I implemented a proof of concept to show what things would look like after
> the deprecation completes:
>
> https://github.com/django/django/pull/6015
>
>
> It removes usage of mark_for_escaping() and EscapeData in the template
> engine to give an idea of what the code might look like with them removed.
> It wasn't difficult to get the tests passing besides a couple modifications
> to tests in test_force_escape.py which don't seem like practical usage
> (chained usage of escape|force_escape).
>
>
> Here's a test case that demonstrates a small behavior change that would
> happen:
>
>
> @setup({'chaining111': '{% autoescape off %}{{ a|escape|add:"

Re: deprecating the "escape" half of django.utils.safestring (#24046)

[Collin Anderson]

Ohh. Nevermind. Sorry for not reading the whole thing. I forgot about
the {% autoescape off %} case.

On Wed, Mar 9, 2016 at 10:11 PM, Collin Anderson 
wrote:

> This makes sense to me. mark_for_escaping() seems like a no-op to me.
>
> On Sat, Mar 5, 2016 at 11:16 AM, Tim Graham  wrote:
>
>> Aymeric raised this ticket [0] while working on multiple template
>> engines:
>>
>>
>> "Since any data that isn't explicitly marked as safe must be treated as
>> unsafe, I don't understand why we have EscapeData and its subclasses nor
>> the mark_for_escaping function. It seems to me that we could keep only
>> the "safe" half of django.utils.safestring and deprecate the "escape" half.
>> As a matter of fact the "escape" isn't used meaningfully anywhere in
>> Django."
>>
>>
>> I implemented a proof of concept to show what things would look like
>> after the deprecation completes:
>>
>> https://github.com/django/django/pull/6015
>>
>>
>> It removes usage of mark_for_escaping() and EscapeData in the template
>> engine to give an idea of what the code might look like with them removed.
>> It wasn't difficult to get the tests passing besides a couple modifications
>> to tests in test_force_escape.py which don't seem like practical usage
>> (chained usage of escape|force_escape).
>>
>>
>> Here's a test case that demonstrates a small behavior change that would
>> happen:
>>
>>
>> @setup({'chaining111': '{% autoescape off %}{{ a|escape|add:"

Re: Proposal on Custom Indexes - Google Summer of Code

[Gavin Wahl]

Would you be able to support partial indexes as well?

On Tuesday, March 8, 2016 at 7:46:02 AM UTC-7, akki wrote:
>
> Hi
>
> My name is Akshesh Doshi (akki). I am a student at Indian Institute Of 
> Technology, Roorkee (IITR). I have been contributing to Django 
>  for quite some time now and 
> my experience has been really great till now. I found the community to be 
> very welcoming and have learnt a lot in this period of time.
>
> With this spirit I would like to work on the idea of "Custom Indexes" 
>   and 
> extend it as my proposal for Google Summer of Code 2016 
> .
>
> I have started preparing my proposal and here is the initial draft 
>  of it. I would like 
> to hear your thoughts regarding this. Also I wanted to discuss some points 
> mentioned below. The timeline still needs work as I am still digging into 
> the code of expressions to see how we can use them in FunctionalIndex. Any 
> pointers/thoughts on that would be appreciated.
>
> Key points:
>   - Introduction to classed based indexes.
>   - Support for custom classes to db_index.
>   - Introduction of Meta.indexes.
>   - Allowing fields to specify their own index type.
>   - Support for a indexes/constraints API. 
>   - Extend expressions into indexes.
>   - Bring spatial indexes under the hood.
>
> Points I would like to discuss:
>  1) Would it be right to *create a IndexTogether class* (subclass of 
> Index) and internally translate Meta.index_together to it ?
>   This would allow something like -
>   class Meta:
>   indexes = [IndexTogether(['field1', 'field2'])]
> I think this would let us keep a better track of any indexes 
> (including those by `index_together`) that are being created. 
> `Meta.index_together` would be internally translated to Meta.indexes. This 
> might also be followed by deprecation of `index_together` if we want.
>
>  2) 
> *Handling Unique constraints via indexes.*  For handling of 
> constraints, I was thinking of creating a UniqueIndex class which would 
> handle any unique constraint on any column and allow other options like to 
> make it deferrable.
>   Right now fields with ``unique=True`` apply the unique constraints 
> by using both the UNIQUE constraint in the CREATE TABLE statement and by 
> creating an index for it. For example, in this model 
> , multiple (repeating) 
> indexes are being generated for the `name` field (one by UNIQUE constraint, 
> 2 others manually, on postgresql). This takes more space and is also not 
> good performancewise. This situation can also be mitigated by keeping a 
> track of all unique constraints at only one place.
>   So I was thinking of bringing the unique constraint totally under 
> indexes. Maybe some `models.UniqueIndex()` could be used in meta.indexes to 
> add constraints ? Any thoughts on it ?
>
>
> I had also prepared a DEP (based on an earlier DEP by Marc Tamlyn), which 
> is now a subset of this proposal.
>
> Regards
> Akshesh Doshi
> (akki)
>

-- 
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/8c3a0f04-4b2a-4c0e-87af-2b9d209681e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[Markus Holtermann]

Hi Akshesh,

thank you for your proposal! Sounds like a good plan.

On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote:

Once the index is added to a model, the model can inject itself into the 
>> index, or the schema editor can use the originating model to get data it 
>> needs. No need to pass the model into the index type I think. Regarding the 
>> name, I'm unsure if I prefer a name=Index() or an Index(name='') approach. 
>> It'd be good to see that choice in your proposal with a couple of pros and 
>> cons.
>>
>
> Well, since we are defining these indexes in a list (to be stored in 
> Meta.indexes) I would go with the Index(name='') approach.
>

I'd prefer the Index(name='') approach

class MyModel(models.Model):
field1 = models.CharField()
field2 = models.CharField()

class Meta:
indexes = [
Index('field1', 'field2', name='some_index_across_two_columns'),
'field2',  # Would be the same as Index('field2'), an index on 
this one column -- name derived from field name: field2_index
Index(ToLower('field1')),  # A functional index on field1 -- 
name derived from field name and functions: field1_tolower_index
]

That way you should also be able to check for duplicate index names.
 

> 1) I don't think it's necessary to have an IndexTogether type. 
>> Index('field_a', 'field_b') should be sufficient I think. If it's not 
>> sufficient, call out why. I'm also in favour of translating any 
>> index_together definitions into appropriate Index types. Then SchemaEditor 
>> only needs to work with Index expressions and things remain simpler at the 
>> boundary between model definition and migrations.
>>
>
> My major concern was about the syntax. Would Index(['f1', 'f2']) mean two 
> indexes (for each field) or one multi-column index. Here we can do 
> something like Index(['f1', 'f2', ['f3', 'f4']]), each element of the list 
> corresponding to a new index.
>
Index(...) would create one index from my perspective. Thus 
Index('field_a', 'field_b') would do the same as 
index_together=(('field_a', 'field_b'),) these days.
Index(['f1', 'f2', ['f3', 'f4']]) looks way to confusing to me. That would 
probably be better Index('f1'), Index('f2'), Index('f3', 'f4')

Since we're talking about index_together, please keep unique_together in 
mind ;)

Cheers

/Markus
 

>
>
>> Of course, this is a great thing to have. But I wonder if we can do 
>> something to prevent pushing non-indexes to the indexes attribute of 
>> Meta. Having Meta.indexes = [CheckTypeConstraint(foo__in=['foo', 
>> 'bar'])] doesn't read correctly. 
>>
>
> Perhaps it would be best not to mix constraints and indexes. I would like 
> to know your thoughts on stopping to create indexes explicitly for unique 
> constraints because all database do that automatically because that only 
> gives a performance degradation as far as I know.
>
>
> On Wednesday, 9 March 2016 12:44:43 UTC+5:30, Anssi Kääriäinen wrote:
>>
>> If the CREATE INDEX part of the generated SQL isn't hard-coded 
>> somewhere outside the Index class, the exact same mechanism can be 
>> used to run other DDL commands, like ALTER TABLE  ADD 
>> CONSTRAINT check_type_choices CHECK (type IN ('foo', 'bar')); 
>>
>> Of course, this is a great thing to have. But I wonder if we can do 
>> something to prevent pushing non-indexes to the indexes attribute of 
>> Meta. Having Meta.indexes = [CheckTypeConstraint(foo__in=['foo', 
>> 'bar'])] doesn't read correctly. 
>>
>>  - Anssi 
>>
>> On Wed, Mar 9, 2016 at 4:20 AM, Josh Smeaton  
>> wrote: 
>> > Hi Akshesh, 
>> > 
>> > The proposal looks really good so far. I haven't gone through it in 
>> depth 
>> > though, but I'll set aside some time to try and do so. A few comments: 
>> > 
>> > - Using the schema editor rather than sqlcompiler is the right choice. 
>> > 
>> > - The earlier part of your proposal seems to focus on allowing postgres 
>> > users to define more complex indexes that they previously haven't been 
>> able 
>> > to use. Oracle is then highlighted also for allowing functional 
>> indexes. I 
>> > think one of the biggest "why's" of this project is to allow users to 
>> define 
>> > custom indexes. It doesn't matter what kind of index. They get access 
>> to the 
>> > stuff that creates them. That should be highlighted before all else. 
>> > 
>> > - Should the type of index (BTree, Spatial, etc) be an index type in 
>> and of 
>> > itself, or should it be a property of a specific index? My knowledge 
>> here is 
>> > limited, so I'm not sure if there are certain constraints on which kind 
>> of 
>> > indexes can use spatial/btree/partial storage types. If certain index 
>> types 
>> > are very heavily restricted, then it probably makes sense to highlight 
>> them 
>> > (as you've done) as a top level class rather than an attribute of 
>> indexes in 
>> > general. If most indexes can be arranged with different storage types 
>> > though, it'd probably make more sense to