On Apr 25, 2008, at 9:22 PM, Malcolm Tredinnick wrote:
> Hold on. One of the reasons a fair bit of effort was put into making
> it
> much easier to subclass model fields is so that we don't have to play
> this endless game of adding every type of specialised field under the
> sun.
>
> If your
I fixed all these problems for me already, Malcolm; but it seems it
may be confusing for some people that Django does not support more
than 4.2G entries in a table out-of-the-box, without such specific
tuning. 4.2G is a really not that large number.
On 26 апр, 06:22, Malcolm Tredinnick <[EMAIL
On Fri, 2008-04-25 at 15:12 -0700, Alex Myodov wrote:
> I am among the people interested in this patch.
> But, looking at the patch concepts from the PostgreSQL perspective, I
> wonder whether it will be possible to use it as a base of native
> BIGSERIAL support in Django (it is likely that
I am among the people interested in this patch.
But, looking at the patch concepts from the PostgreSQL perspective, I
wonder whether it will be possible to use it as a base of native
BIGSERIAL support in Django (it is likely that MySQL supports
something similar, but sqlite needs
http://code.djangoproject.com/ticket/399
I notice this ticket has been around for a while, and according to the
comments, was only waiting a Triage member to look it over.
SmileyChris was nice enough to point me over to this group to ask
about it.
Also, the most resent patch was missing
Am Montag, 10. Dezember 2007 05:31 schrieb Aaron Krill:
> Hello,
>
> I recently commented on ticket #399 regarding why the check-in of this
> patch should not be delayed, and I would like permission to please
> change the status of this ticket back to "Ready for check-in." This
> field is very
Hello,
I recently commented on ticket #399 regarding why the check-in of this
patch should not be delayed, and I would like permission to please
change the status of this ticket back to "Ready for check-in." This
field is very important for myself, and as evidenced by the level of
communication
Ivan,
Thanks for the idea.
cheers
Darren
Ivan Sagalaev wrote:
Darren Redmond wrote:
I could not find any way to make the Integer Field use the int8 type
without changing the django db mappings code,
I once hacked it with initial SQL that changed column type after
creation:
ALTER
Darren Redmond wrote:
I could not find any way to make the Integer Field use the int8 type
without changing the django db mappings code,
I once hacked it with initial SQL that changed column type after creation:
ALTER TABLE "table" DROP COLUMN "column";
ALTER TABLE "table" ADD COLUMN
the int8 type
without changing the django db mappings code,
so I've had to switch to using a CharField which I think is a bit
smelly, and would prefer not to do.
Is there a BigIntegerField or would it be better to use a FloatField, or
is there some other way of achieving this that I am missing
Felix Ingram wrote:
> On 8/22/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> >
> > I'd like an integer field larger than postgresql's integer (2^31).
> >
> > Any interest in a patch for BigIntegerField?
>
> Matt Croydon submitted a patch a while ago:
>
I have wanted this as a built in "Type" for some time. I usually just
do some manual SQL to alter the columbs that I need to be "Big
Integers", but it would be nice to have them built in, especially for
the default row id created for each table. Hopefully this will make
its way into the trunck
On 8/22/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> I'd like an integer field larger than postgresql's integer (2^31).
>
> Any interest in a patch for BigIntegerField?
Matt Croydon submitted a patch a while ago:
http://code.djangoproject.com/ticket/399
It might n
I'd like an integer field larger than postgresql's integer (2^31).
Any interest in a patch for BigIntegerField?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
14 matches
Mail list logo
