On Thu, 2006-07-20 at 02:25 +, DavidA wrote:
>
> Malcolm Tredinnick wrote:
> > I was trying to avoid a hash-based solution because it leads to
> > unreadable names (and I don't think every database supports unnamed
> > constraints, so that isn't a universal solution, either). I need to do a
Malcolm Tredinnick wrote:
> I was trying to avoid a hash-based solution because it leads to
> unreadable names (and I don't think every database supports unnamed
> constraints, so that isn't a universal solution, either). I need to do a
> bit of research and them come up with a legal hash
On Thu, 2006-07-20 at 00:39 +, DavidA wrote:
>
> Malcolm Tredinnick wrote:
> > On Wed, 2006-07-19 at 11:24 +, DavidA wrote:
> > > MySQL requires each constraint to have the same name.
> >
> > I'm pretty sure you meant to say "different name" there. :-)
>
> Oops. I guess that's what the
I got sick of waiting so attempted it myself.
http://code.djangoproject.com/ticket/61
It all works for me, the only thing it needs is some tests and work on
the "rel" stuff (which is used if it's used with edit_inline I think?).
But it is a complete working patch, feel free to test it out /
Malcolm Tredinnick wrote:
> On Wed, 2006-07-19 at 11:24 +, DavidA wrote:
> > MySQL requires each constraint to have the same name.
>
> I'm pretty sure you meant to say "different name" there. :-)
Oops. I guess that's what the "preview" button is for.
> The problem should be fixed in r3373
Hi,
I would like to use Django with MS-SQL server and the svn version
doesn't work yet.
I submitted a patch to make it work:
http://code.djangoproject.com/ticket/2358
It's not ideal, just a quick fix until I get a better understanding of
Django internals.
What is missing right now is
> 'escape' and 'safe' have a different meaning for fireworkers, too ;-)
Or bank robbers :-P
Back on topic, I like finalization too (even though I cringe having to
write the american Z version).
--~--~-~--~~~---~--~~
You received this message because you are
Simon Willison wrote:
> I don't see any harm in META using unicode strings, whereas
> if it were to use bytestrings our documentation ends up being that
> little bit more confusing (we can't just claim everything is a
> unicode string).
We can't do it anyway. First example is
now i'm on my django site
https://example.org/
if I type https://example.org/admin it redirects to http://example.org/admin/
(note the change from https to http)
is this an expected behaviour?
Thanx
--~--~-~--~~~---~--~~
You received this message because you
I know you guys have discussed the problems with binary data in the
ORM. But I have never seen a very comprehensive explanation of why this
is so bad. I have 3million binary images in my current postgres cluster
and it works quite well.
I would love to use the ORM for managing some of these
On 19 Jul 2006, at 15:43, David Larlet wrote:
> I'd like to know if it's possible to have access to django slides of
> Simon's conf at Europython 2006.
I've uploaded my slides to the conference site:
http://indico.cern.ch/contributionDisplay.py?
contribId=26=9=44
They're a 22 MB PDF file.
On 19 Jul 2006, at 15:30, Ivan Sagalaev wrote:
> I just thought that may be they shouldn't. If META is a reflection of
> CGI's environment that is derived from HTTP environment that is
> essentially in byte strings then I think META being unicode is may be
> useless and misleading.
>
> Instead
Hi!
I'd like to know if it's possible to have access to django slides of
Simon's conf at Europython 2006. Maybe I haven't found those but there
are not listed on the official page:
http://indico.cern.ch/sessionDisplay.py?sessionId=9=44
Cheers,
David Larlet
Simon Willison wrote:
> request.META should contain unicode strings that directly reflect the
> underlying raw bytestrings
I just thought that may be they shouldn't. If META is a reflection of
CGI's environment that is derived from HTTP environment that is
essentially in byte strings then I
On 19 Jul 2006, at 14:37, Gábor Farkas wrote:
> 1. request.META should contain raw bytestrings (like it's currently)
> 2. request.META should contain unicode strings. for QUERY_STRING, we
> should convert it to unicode using the 'ascii' charset. and we should
> not url-decode it.
request.META
Simon Willison wrote:
>
> On 19 Jul 2006, at 13:19, Ivan Sagalaev wrote:
>
>> Talking about QUERY_STRING... While the string itself is in ASCII
>> it has
>> urlencoded data and there the encoding matters. As fas as I can see in
>> practice browsers tend to encode those data in the same
Simon Willison wrote:
> We shouldn't be decoding QUERY_STRING in request.META at all - we
> should leave it as urlencoded ASCII. request.META is meant to give
> you access to the 'raw data' from the browser.
>
> We do however need to take charset stuff in to account when creating
> the
On 19 Jul 2006, at 13:19, Ivan Sagalaev wrote:
> Talking about QUERY_STRING... While the string itself is in ASCII
> it has
> urlencoded data and there the encoding matters. As fas as I can see in
> practice browsers tend to encode those data in the same encoding as
> the
> page from where
jeremy bornstein wrote:
> In some circles, "finalization" is what happens to an object immediately
> before it is GC'd, so this choice may end up being confusing. This is
> the case with respect to Java, for example.
Doesn't keep me from liking it, and Java is not python. Probably
each and
Simon Willison wrote:
> In the absence of anything better than that, I think it's safe to
> assume that CGI environment variables should always be ASCII encoded.
Talking about QUERY_STRING... While the string itself is in ASCII it has
urlencoded data and there the encoding matters. As fas as
On Wed, 2006-07-19 at 11:24 +, DavidA wrote:
>
> Alexis Smirnov wrote:
> > ALTER TABLE `console_restoreevent` ADD CONSTRAINT
> > `identity_id_referencing_console_identity_id` FOREIGN KEY (`identity_i
> > d`) REFERENCES `console_identity` (`id`);
> > ALTER TABLE `console_backupevent` ADD
Bill de hÓra wrote:
> gabor wrote:
>
>> questions:
>> 1. django publishes the whole environ dictionary as request.META. the
>> environ dictionary is a normal byte-string dictionary. so, should we
>> convert it to unicode so that the request.META dictionary only contains
>> unicode strings?
>>
gabor wrote:
> questions:
> 1. django publishes the whole environ dictionary as request.META. the
> environ dictionary is a normal byte-string dictionary. so, should we
> convert it to unicode so that the request.META dictionary only contains
> unicode strings?
>
> 1.a: if yes, how? some
Alexis Smirnov wrote:
> ALTER TABLE `console_restoreevent` ADD CONSTRAINT
> `identity_id_referencing_console_identity_id` FOREIGN KEY (`identity_i
> d`) REFERENCES `console_identity` (`id`);
> ALTER TABLE `console_backupevent` ADD CONSTRAINT
> `identity_id_referencing_console_identity_id`
On 18 Jul 2006, at 23:30, gabor wrote:
> 1. django publishes the whole environ dictionary as request.META. the
> environ dictionary is a normal byte-string dictionary. so, should we
> convert it to unicode so that the request.META dictionary only
> contains
> unicode strings?
>
> 1.a: if yes,
On Wed, 2006-07-19 at 00:30 +0200, gabor wrote:
> questions:
> 1. django publishes the whole environ dictionary as request.META. the
> environ dictionary is a normal byte-string dictionary. so, should we
> convert it to unicode so that the request.META dictionary only contains
> unicode
Gábor Farkas wrote:
> i somehow have the feeling that we lost the original idea here a little.
>
> (as far as i understand, by urlify.js we are talking about slug
> auto-generation, please correct me if i'm wrong).
>
> we are auto-generating slugs when it "makes sense". for example, for
>
Although it is an old problem and perhaps some of you already have
ways to solve it, I have noticed the same problem just a few hours ago
too, and I would like to share with a couple of solutions for that.
1. Use ForeignKey for ONE TO ONE relationship:
user = models.ForeignKey(User, unique=True,
Antonio Cavedoni wrote:
> On 17 Jul 2006, at 8:25, tsuyuki makoto wrote:
>> We Japanese know that we can't transarate Japanese to ASCII.
>> So I want to do it as follows at least.
>> A letter does not disappear and is restored.
>> #FileField and ImageField have same letters disappear problem.
>>
On 17 Jul 2006, at 8:25, tsuyuki makoto wrote:
> We Japanese know that we can't transarate Japanese to ASCII.
> So I want to do it as follows at least.
> A letter does not disappear and is restored.
> #FileField and ImageField have same letters disappear problem.
>
> def slug_ja(word) :
> try
On 19-Jul-06, at 12:33 PM, Malcolm Tredinnick wrote:
>
> On Wed, 2006-07-19 at 12:08 +0530, Kenneth Gonsalves wrote:
>>
>> On 19-Jul-06, at 11:46 AM, Brantley Harris wrote:
>>
>>> You keep #django open too and answer questions in there. Therefore
>>> they have no reason to enter #django-devel.
On 19-Jul-06, at 11:46 AM, Brantley Harris wrote:
> You keep #django open too and answer questions in there. Therefore
> they have no reason to enter #django-devel.
dream on - you can never escape crazies and retards
--
regards
kg
http://lawgon.livejournal.com
You keep #django open too and answer questions in there. Therefore
they have no reason to enter #django-devel.
On 7/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>
>
> On 19-Jul-06, at 1:31 AM, Brantley Harris wrote:
>
> >
> > Being tired of all the craziness and mundane questions of
33 matches
Mail list logo
