Re: BigAutoField
On 23 tammi, 16:09, SteveB wrote: > Hi, > Can anybody provide an update on the request to define a BigAutoField in > Django? > We could really use this model field type without having to do workarounds > and customizations. > Can any of the Django developers comment on when this will be released? There isn't any release schedule for features like this. I have been playing around an idea of having an AutoGeneratedField(). The basic idea is that such a field has to components, internal_field, and generator. The internal field is a field that stores the data. The generator is an object that generates values for that field on save. The generator API would be something like this: pre_save(self, field, obj, connection, created) returning(self, field, obj, connection, created) post_save(self, field, obj, connection, created, returned_vals) Consider AutoField as an example. Here the internal_field is an IntegerField, and the generator is a SerialGenerator. For autofield the definition would be something like this (just MySQL and PostgreSQL support to make this example shorter): pre_save(): return NotImplemented returning(self, field, obj, connection, created): if created and connection.vendor == 'postgres': return field.column return NotImplemented post_save(self, field, obj, connection, created, returned_vals): if created and connection.vendor == 'mysql': setattr(obj, field.attname, connection.insert_id()) elif field in returned_vals: setattr(obj, field.attname, returned_vals[field]) In reality the SerialGenerator implementations should be done in connection.ops for 3rd party backend support. For this example that would just complicate things. Why this way? Well, a UUIDGenerator would be: def pre_save(self, field, obj, connection, created): if created: setattr(obj, field.attname, generate_uuid()) (or, you could use returning() if you want to generate the value in the DB). BigAutoField? AutoGeneratedField(internal_field=BigIntegerField, generator=SerialGenerator). I am pretty sure we could make this work. This would also allow doing DateTimeField with default of database generated now() for created/ modified times. Or, maybe there is some trigger modifying some field's value on save, and you want to return that back to Python on save. There are a lot of details. The API likely doesn't work as-is (database creation SQL at least needs some support). I don't think I will have time to work on this anytime soon. This is likely going to take a lot of time to do properly. (Yeah, I know, implementing all this is a bit overkill if all you want is BigAutoField). - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: BigAutoField
Hi Steve, Django is an open source product made and improved by many volunteers. Probably you are reffering to: https://code.djangoproject.com/ticket/14286 What needs to get done to get the patch accepted in Django, is that somebody (really anybody - could be you) looks at the latest patch provided. maybe makes some improvements for suggestions and if all is well, it can be marked: Ready for checkin. After that, it is a core developers "job" (again, it is voluntary) to either implement, or give constructive feedback on why not. Some tickets are easy and some are hard. The best way to get a core developers attention is to do a 5 for 1, which means if you check 5 patches of other people, a core developer is willing to look at your patch / the patch you would like to have in Django. More information on contributing to Django is here: https://docs.djangoproject.com/en/dev/internals/contributing/ Good luck! Wim On Wednesday, 23 January 2013 15:09:29 UTC+1, SteveB wrote: > > Hi, > Can anybody provide an update on the request to define a BigAutoField in > Django? > We could really use this model field type without having to do workarounds > and customizations. > Can any of the Django developers comment on when this will be released? > > Thanks, > Steve -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
BigAutoField
Hi, Can anybody provide an update on the request to define a BigAutoField in Django? We could really use this model field type without having to do workarounds and customizations. Can any of the Django developers comment on when this will be released? Thanks, Steve -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: FloatField, localize and Django settings
Thanks for your feedback. For reference, ticket is #19656 ( https://code.djangoproject.com/ticket/19656#ticket) 2013/1/22 Wim Feijen > Hi Michael, sounds very reasonable to me. Could you please file a bug > ticket for that at https://code.djangoproject.com/newticket ? > > > On Tuesday, 22 January 2013 21:30:09 UTC+1, Michael Anckaert wrote: > >> Hello everyone >> >> I came across an issue where my CBV and an automatic ModelForm gave me >> some headaches with localization. >> >> The project is localized so a float is 3,2 instead of 3.2 (comma instead >> of dot) but the CBV UpdateView didn't handle the localization of the float. >> After tracking through the sources I noticed that the attribute localize >> of FloatField has to be set manually. >> >> Wouldn't it be sensible to localize the FloatField according to the >> project settings instead of having to manually set it in a custom form? >> >> Kind regards >> Michael Anckaert >> michael@sinax.be >> http://www.sinax.be >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/BFrsjaJD0hMJ. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Kind regards Michael Anckaert http://www.sinax.be -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.