Re: BigAutoField

2013-01-23 Thread Anssi Kääriäinen 
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

2013-01-23 Thread Wim Feijen 
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

2013-01-23 Thread SteveB 
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

2013-01-23 Thread Michael Anckaert 
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.