On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> However, I was under the impression that this has the effect of
> disabling, not just deferring key checks - that is, if you disable
> checks, load bad data, then re-enable checks, no errors will be
> raised. We don't want to be res
On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> (2) provide a way to manually disable and re-enable integrity checks. If
> someone with more MySQL-fu than me knows how to do either of these
It should work:
SET FOREIGN_KEY_CHECKS = 0;
... imported data ...
mysql> SET FOREIGN_KEY
On 6/17/08, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> Link comes out broken by Google Groups web interface.
I see - is there a way how to pass such URL via Google interface?
> Anyway, in the mod_python case it comes down to Location directive
> being used. The SCRIPT_NAME/PATH_INFO varia
> I though that might be the case, I won't bother to raise a ticket then.
We had a similiar problem and discussed it on Apache forum: perhaps it
could enlighten a problem:
http://mail-archives.apache.org/mod_mbox/httpd-users/200708.mbox/[EMAIL
PROTECTED]
HTH, Peter
--~--~-~--~~
On 6/9/08, Ian Kelly <[EMAIL PROTECTED]> wrote:
> I don't know why this is so mysterious. A small amount of browsing
> turns up that the code was added in revision [4916] and specifically
> enabled for Oracle only to fix ticket #3743.
But it does not explain why ticket #3030 has been closed
On 6/10/08, Eric <[EMAIL PROTECTED]> wrote:
> I'm not certain that this route is perfect, but it seems to be a
> compromise of both worlds.
We use the same approach with mean time redundancy about 1 months.
Peter
--~--~-~--~~~---~--~~
You received this messag
On 6/9/08, James Bennett <[EMAIL PROTECTED]> wrote:
> So please, in all honesty, tell me why you think Django's development
> process isn't "visible" enough for people who are concerned and want
> to get information.
I give you example: few weeks ago I discovered that problem #3030
still per
On 11 Kvě, 15:17, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Again, no argument here. Care to contribute a fix? :-)
At least I'd like, because of working evolutions are our vital
interests...
This is the reason I opened a discussion here, whether it is safe:
- set kwargs['unique'] = Fa
On 11 Kvě, 11:25, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Django has made a subtle change to the way a OneToOne field definition is
> interpreted.
> This change makes sense, and is documented as being backwards incompatible.
Yes, I agree and respect it. OTOH, this is no reason to ge
On 10 Kvě, 18:06, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> > Setting kwargs['unique'] = False in OneToOneField constructor
> > supresses this, but I don know if there are no other dependencies...
>
> Is the UNIQUE causing a problem?
In conjuction with primary key 'per se' probably not. At le
On 10 Kvě, 18:08, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> > Is there a way the DatabaseFeatures would supply different values for
> > different versions of configured SQL server?
>
> This question fits better on the user's list, I believe.
This question is related to ticket #3030, because
Is there a way the DatabaseFeatures would supply different values for
different versions of configured SQL server?
Thanks, Peter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to t
I notices that refactored OneToOneField creates artificial primary key
as UNIQUE, whereas all other primary keys generated by Django omits
such declaration, because it is inherent (at least on MySQL)
Setting kwargs['unique'] = False in OneToOneField constructor
supresses this, but I don know if t
Hi all,
I've a question, why max. size of User.email field is set to 75
characters,
if RFC 2821 limits local part to 64 characters and domain to 255.
With '@' it is together 320 chars.
Should not be this field extended?
--~--~-~--~~~---~--~~
You received this me
14 matches
Mail list logo
