... or perhaps "prostrate" ... or "prostitute" ... you never can
tell these days ...
On 24.04-08:24, Sells, Fred wrote:
> I think he meant “persecute”
>
>
>
> From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On
> Behalf Of Mark Phillips
> Sent: Thursday, April 12,
On 20.03-23:53, andrew wrote:
[ ... ]
>I encounter a issue lasting 3 days, any help will be highly
> appreciate.
your question is too vauge (to me) to be "assistable". i can only
ask if you've done the tutorials (which are pretty good) and if so
then suggest you try including more complete
On 08.01-13:00, Malcolm Tredinnick wrote:
[ ... ]
> > a 'blank' value is essentially undefined in database terms and may be
> > interpreted in various ways.
>
> Not, that's a NULL value. Blank has absolutely no technical meaning at
> the database level and certainly not any kind of ambiguous
On 07.01-13:40, Jeff Anderson wrote:
[ ... ]
> > please troll somewhere else.
> >
> I wasn't trolling, thank you. I was genuinely interested in how this
> would look.
my apologies, i mis-read your terse questioning.
a 'blank' value is essentially undefined in database terms and may be
On 07.01-08:51, Jeff Anderson wrote:
> > I agree with this. I use null=False, blank=True for some ImageFields
> > and integers.
> I'm interested in how a blank integer looks in a MySQL database. Can you
> provide an example?
please troll somewhere else.
On 06.01-16:55, Victor Hooi wrote:
[ ... ]
> Valts, thanks for the reply - that looks interesting, and is similar
> in some ways to what I want - definitely going to check out the code.
> Basically, I just wanted a simple file-upload form, for the user to
> upload the two .CSV files. Then,
On 07.01-09:47, Malcolm Tredinnick wrote:
[ ... ]
> This thread is about whether blank=True, null=False (the fourth
> possibility) ever makes sense for non-text fields.
answer is yes for any field type that accepts an empty string as having
a meaning. i currently use this for a couple of custom
On 06.01-08:03, dchandek wrote:
> [ ... ] But shouldn't this be addressed in the
> validation code?
ps: no, the validation code would exist as it currently does. i am
only suggesting a change in convention, not the actual options or
their meanings.
On 06.01-08:03, dchandek wrote:
[ ... ]
>> i would be against unifying the options as i can imagine a more complex
>> environment (i.e. a database trigger or complex type not known to
>> django) where there may be a distinction and i believe the current
>> distinction is a clear one. it may be
On 06.01-07:38, Lee Braiden wrote:
[ ... ]
> On Tue, 2009-01-06 at 00:05 -0700, Jeff Anderson wrote:
> > Malcolm Tredinnick wrote:
> > > I don't think we'd want to get too subtle here. Either it makes
> > > sense for all non-text fields, or it doesn't.
> > Agreed I simply haven't spent any time
On 03.01-02:10, Szymon wrote:
[ ... ]
> So there is any other working solutions for migrating MySQL ->
> Postgre?
i would suggest that you do this via the database not via django.
simply alter your 'settings.py' to point to your new postgres database
and sync it to create all the relevant
On 12.12-08:28, Ana wrote:
[ ... ]
> Thank you both for the suggestions. There is a problem with the
> sequence number in the primary keys. When I created a new table
> without data the insert worked fine.I will try to recreate the
> sequences and hope I don't have to re-enter the data.
On 04.12-20:22, Florian Lindner wrote:
[ ... ]
> I use the comments framework from the newest Django SVN checkout.
sorry to not be of more help (i've never used the comments framework)
but i can only suggest that you select a release version and not the
'newest' (i'm assuming that means trunk).
On 01.12-07:59, Fergus wrote:
[ ... ]
> > bit worrying that you consider the traceback to be 'gumph' ...
>
> Gumph in the sense that it didn't seem awfully relevant in this case,
> as the exception was reasonably self-explanatory. I'm very grateful
> for Python's stack trace in other
On 19.10-11:37, Jorge Romo wrote:
[ ... ]
> I want to validate a form, but it has several different options. It
> has to take a value_a and the see if it is bigger, smaller or equal to
> another value_b. The issue (or maybe not :p) is that the value_b is
> entered by the user, so it is always
15 matches
Mail list logo
