be the only place (within Django itself) where any
of these processes are automated across multiple DBs at the moment?
FWIW I *always* forget that I have to explicitly call syncdb for each
database, and expect the one call with no db specified to have done the
lot.
Cheers,
Nick
--
Nick Phillips /
press and starting another one?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are subscribed to the Google Groups
"Django developers" grou
diately
think of several people who, on finding that they can't do what they
want with raw(), would naturally progress to writing a postgres function
to do the dirty work (on the grounds that that can then be called using
"select").
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195
403, a redirect
to homepage, a forced logout with disabling of account and email to
admin, could be all sorts of things, depending on the site.
The question should probably be "how can we allow the developer to
specify the desired behaviour when the user attempts to access a URL to
which they h
i-line tags?
Do all the arguments really have to be within the single tag?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are subscribed to the Google Gro
ses decimals instead of
> floats.
>
Not if you have a "legacy" database which uses NUMBER, I'm guessing...
I'd have thought the inability to work with any particular common field
type should be a bug, as it could effectively prevent working with
non-managed models al
on on at all times and allow us to ensure we get the right
hosts in the right environments?
What am I missing?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message becaus
On Tue, 2013-02-19 at 15:46 -0700, Carl Meyer wrote:
> Hi Nick,
>
> On 02/19/2013 03:32 PM, Nick Phillips wrote:
> > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> > do, it seems rather problematic. In particular, that host verification
> >
em to get the message).
I suggest you take Russell's post at face value, by the way. "Looking
for a positive outcome".
Well, perhaps face value plus a head of frustration that he's hiding
fairly well.
Thanks again to all of you who are making it happen.
Cheers,
Nick
--
therefore never use the runserver at all...
Cheers,
Nick
--
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago
--
You received this message because you are subscribed to the Google Groups
"Django developers"
information on the "foo" command, if not always the
full docs (g info gr). So I'd suggest considering implementing
something to generate a man page from whatever you wish the "canonical"
source of the information to be.
Cheers,
Nick
--
Nick Phillips / nick.phill.
ry, which could be handled by generating an index in one of two
different ways), there are absolutely no security implications involved
in the decision (or lack of decision ;-) ) that is currently being
discussed.
FWIW, I personally dislike extraneous slashes. Django views seem to me
to be analogous
/foo/ and /foo/index.html
usually being equivalent )
was correct. I think you're probably just looking at it from a different
angle.
As someone else pointed out, it's very likely moot at this point anyway.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
r magic-removal to stabilise.
Knowing what I do now, I don't know whether I'd use magic-removal --
damned if I do, damned if I don't.
So yes, you're absolutely right. And my timing is, as usual, awful.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED]
ow.
And thanks for everything so far; it looks like this could be quite
enjoyable :-)
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED]
# these statements are my own, not those of the University of Otago
--~--~-~--~~~---~--~~
You rece
- and if I did want to, I wouldn't expect to get
anywhere with your current tactic.
This thread is distracting energy that could be better spent, so I'm
going to leave it at that, and would suggest that others do too.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@o
portunity to refactor slightly more and ensure that all munging of
data took place in one method which could then be used for the purpose
described above - which worked just fine.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not
mmediately
LOG_CRIT critical conditions
LOG_ERRerror conditions
LOG_WARNINGwarning conditions
LOG_NOTICE normal, but significant, condition
LOG_INFO informational message
LOG_DEBUG debug-level message
Cheers,
Nick
--
Nick Ph
ly as possible. Since
their issue is buried within the framework and can't easily be
overridden, I think their ubiquity does justify the the lower priority.
However, as Alex pointed out, this is essentially bikeshedding. So,
since you're the one doing the work, at this point I'll shut
would both manage separate
keys for each requirement, and actually allow the keys to be refreshed
without invalidating existing otherwise-valid HMACs?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Ota
t; However, I don't think we should delay this change for the sake of that
> ideal.
Makes sense. What you're doing is clearly an improvement, and one with
no cost to the user involved in making the change, so...
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otag
21 matches
Mail list logo
