Re: Ticket #399 -- bigint support

[Jacob Kaplan-Moss]

On Wed, Dec 16, 2009 at 1:04 PM, Karen Tracey  wrote:
> I've uploaded what I think is a commit-ready patch for adding
> BigIntegerField.  Barring any major objections I'd like to commit this in
> the next day or two.

Looks good to me - go ahead.

Jacob

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[Karen Tracey]

I've uploaded what I think is a commit-ready patch for adding
BigIntegerField.  Barring any major objections I'd like to commit this in
the next day or two.

Karen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[Martin Omander]

In my very first Django app I ran into the int limitation and my app
wouldn't work. It was quite confusing for a newbie Django user, as
every other toolkit and database I have ever used supported long
integers. My app integrates with Twitter, and it was the id field of
tweets from Twitter that broke the int limit. As I'm writing this, new
tweets are given ids around 6.6 billion.

Thinking back to my consulting days, we often used long integers when
integrating different systems. I think it would be very helpful if
Django supported long integers out of the box, as most databases do.
If it is determined that long integers shouldn't be natively
supported, I think the code for how to define your own long integer
field should be added as a note to the Django docs. That way other
newbie Django users won't have to spend time chasing down the answer
in the blogosphere like I did.

All the best,

/Martin


On Dec 12, 10:29 am, Manu  wrote:
> Gosh... copy paste was a bit fast... ti 
> washttp://code.google.com/p/django-iptocountry/
>
> Manu

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[Manu]

Gosh... copy paste was a bit fast... ti was 
http://code.google.com/p/django-iptocountry/

Manu

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[Manu]

Hi,

I have just subscribed and do not know how much power I'll have
through my post... :) but just to let you know: I ran into the need of
a bigint on postgresql installing (and refactoring a bit)
http://code.google.com/p/django-countryip/

I changed the integer to bigint directly in the base and would
have appreciated an BitIntegerField.

Manu

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[James Bennett]

On Wed, Dec 9, 2009 at 8:10 PM, Karen Tracey  wrote:
> Yes, it's easy to do yourself.  But to me this seems like an oddly basic
> type to be missing from the base, with enough users potentially wanting it
> that it deserves to be officially supported.  So I'd be willing to spend
> some time on it, but I don't want to waste time if that -1 stands in the way
> of checking it in.  James: how adamant are you on the -1?  Would you
> consider -0 instead?

I was unaware that I wielded such power :)

Basically, I gave it a -1 because I've never actually run into a
situation where I've needed it, and I've done a *lot* of Django
development over the years. But don't let that stand in the way if
it's something y'all really want.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[Karen Tracey]

2009/12/10 Tomáš Kopeček 

>
> We've fixed all issues (like incomplete tests and few bugfixes), so
> patch is now ready to be included into trunk.
>
> I partially agree with -1 vote. It is easy. What is against: Included in
> trunk we address all backends (and it looks to be easy to maintain them)
> and second point: we have some unit tests.
> So finally I am more for inclusion than 'wontfix'.
>
>
Actually, there is an issue related to "all backends" support.  We can only
add the necessary code for the backends that Django ships.  There are also
externally maintained backends, which won't support big integer fields
without some changes.  Currently, the behavior when using a backend that
doesn't have a mapping for the new field is not ideal (I noticed this when
trying out the patch that had a mistake in the sqlite mapping, resulting in
sqlite having no mapping for the new field).  Syncdb ran fine, but the table
created was simply missing any big integer columns.  I think it would be
better if the syncdb failed with a clear message that the backend in use
doesn't support that type of field.

Now, it may be that from a practical point of view this will not really be a
fix that is needed.  If "old" external backends are going to fail loudly on
1.2 due to other core Django changes (I'm thinking multidb) then perhaps it
will be clear to anyone using an external backend that a new version of it
is needed for 1.2, and that new version would hopefully support the new
field type.  From a purist of view I still think syncdb should handle the
situation better, but from a practical point of view its current behavior
may not actually trip anyone up.  And it's not really something I wanted to
give a lot of thought to before determining whether this ticket can move
forward.

Karen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Ticket #399 -- bigint support

[Tomáš Kopeček]

> I think ticket #399 could make it into 1.2, but there's a -1 vote (from
> James) to overcome first: Patch on the ticket (which is over a year old)
> indicates how easy this is to do yourself if you need it.
>
> The patch is no longer a year old, it's been updated a few times
> recently, fixing tests to get it to work on multiple backends for instance.
>
> Yes, it's easy to do yourself.  But to me this seems like an oddly basic
> type to be missing from the base, with enough users potentially wanting
> it that it deserves to be officially supported.  So I'd be willing to
> spend some time on it, but I don't want to waste time if that -1 stands
> in the way of checking it in.  James: how adamant are you on the -1?
> Would you consider -0 instead?
>
> Karen

We've fixed all issues (like incomplete tests and few bugfixes), so
patch is now ready to be included into trunk.

I partially agree with -1 vote. It is easy. What is against: Included in
trunk we address all backends (and it looks to be easy to maintain them)
and second point: we have some unit tests.
So finally I am more for inclusion than 'wontfix'.

Tomas (Permon)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.