Can Length method of django.db.models.functions applicable to BigIntegerField?

I need to filter data by it's value length of a field. I can do it in a for loop, but I'm curious about if the Length method can be applicable to any type of field besides CharField -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscrib

Changing Primary Key from BigAutoField to BigIntegerField not working

Hello. I'm using postgresql 12 and psycopg2, Python 3.7, Django 3.0.2 (actual stable branch) I declared first my Model with a BigAutoField as Primary_key, later i menchend that the ID field is unique, the id's are predefined and unique. I tried to change the id to a BigIntegerFie

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

That's a good snippet, but I am sticking with django.contrib.auth.models.user.id = BigIntegerField(primary_key=True) for now. On Jan 10, 11:46 pm, Eric Chamberlain wrote: > We used one of the UUID fields from djangosnippets.org > <http://www.djangosnippets.org/snippets/335/>. &

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

We used one of the UUID fields from djangosnippets.org . On Jan 9, 2010, at 6:56 PM, G B Smith wrote: > Eric, could you explain how this UUID implementation was achieved? > Django doesn't have a built-in UUID, so I can only guess that you used > a v

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

I assume you could checksum some form of the user's object or "cleaned" form values and store it as unique attribute of the users. You would prolly have to override the clean method and add in valudation of the uniqueness and generate using an alternate method if the first does not validate

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

Eric, could you explain how this UUID implementation was achieved? Django doesn't have a built-in UUID, so I can only guess that you used a varchar field within Django. ? On Jan 10, 2:29 am, Eric Chamberlain wrote: > On Jan 9, 2010, at 8:59 AM, G B Smith wrote: > > > Thanks, that is a good resour

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

On Jan 9, 2010, at 8:59 AM, G B Smith wrote: > Thanks, that is a good resource. So this is what I am going to do : - > -- modify the contrib.auth.models.user to explicitly include id = > models.BigIntegerField(primary_key=True) > -- modify the contrib.auth.models.user.id field in the database usi

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

Thanks, that is a good resource. So this is what I am going to do : - -- modify the contrib.auth.models.user to explicitly include id = models.BigIntegerField(primary_key=True) -- modify the contrib.auth.models.user.id field in the database using creecode's method above or via the mysql shell or ph

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

Hello GBS, You might be able to accomplish this with the use of signals.post_syncdb. An adaptation the technique discussed here < http://onebiglibrary.net/story/automatically-create-mysql-fulltext-index-with-django-syncdb > to alter your column might do the trick. On Jan 8, 10:24 pm, G B Smith

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

cally increment. On Jan 9, 10:21 am, G B Smith wrote: > Yes, I have read that thread. But since BigIntegerField is now > available within Django, I would like to handle it from within Django > itself. > > Thus I want to knowif changing the contrib.auth code to explicitly > include a

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

Yes, I have read that thread. But since BigIntegerField is now available within Django, I would like to handle it from within Django itself. Thus I want to knowif changing the contrib.auth code to explicitly include a BigIntegerField primary key will have any side-effects (for example in

Re: handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

y app is going to be > very really really high. And let's also say I want to use the > contrib.auth as it is so convenient. > > Is it okay if I simply change the code of django.contrib.auth.user to > explicitly include an BigIntegerField called id and manually set it to >

handle astronomically high number of users via the new BigIntegerField and contrib.auth.user

Greetings, Let's say I know that the number of users of my app is going to be very really really high. And let's also say I want to use the contrib.auth as it is so convenient. Is it okay if I simply change the code of django.contrib.auth.user to explicitly include an BigIntegerField

Re: BigIntegerField

That patch is all that's available, AFAIK. On 4/19/07, Stephan Jennewein <[EMAIL PROTECTED]> wrote: > > Hi, > > is there something like a BigIntegerField for the models.py ? > I need an integer bigger than 4 byte. > > I found a patch for revision 3000

BigIntegerField

Hi, is there something like a BigIntegerField for the models.py ? I need an integer bigger than 4 byte. I found a patch for revision 3000 but it doesn't work. Stephan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the G

Re: BigIntegerField type?

On 1/27/06, Roberto Aguilar <[EMAIL PROTECTED]> wrote: > But in the mean time, is the best thing to do simply manually alter > the database? i.e.: > > ALTER TABLE foo_bars ALER some_number TYPE bigint; > > I tried this and it works fine, but does anyone see something going > wrong with this? Hi R

BigIntegerField type?

Hello, I'm in need to store really big numbers in the database. It looks like the only limitation to this is that there is no BigIntegerField type to use. I found this bug, which covers the problem: http://code.djangoproject.com/ticket/399 But in the mean time, is the best thing to do s