Hey Steve,
Thanks for the suggestions. Setting aside the matter of using extends
vs. include, or using data-driven menus vs. hardcoded menus, the key
issue is how to figure out which of the links corresponds to the
current page.
>From your code sample, it looks like you're comparing
Amit Upadhyay wrote:
> 1. make sure none of your apps do db writes on GET. [It was the case
> with my entire project already, other than one case, which was trivial
> to work around].
> 2. Use non db session backend.
> 3. Not use auth messages. [This presented some problems for me, but I
> had
On Fri, Oct 17, 2008 at 7:10 PM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
>
> Amit Upadhyay wrote:
>> The crux of that solution is the middleware:
>>
>> def process_request(self, request):
>> state = request.method in ['GET', 'HEAD'] and 'slave' or 'master'
>>
How about we raise a validation error on UNIQUE CharField fields
greater than 255 characters for all MySQL 5.0 implementations.
I think the docs should be updated as well telling people that it's
not best practice to use CharField for fields that need more than 255
characters (or at least put a
Amit Upadhyay wrote:
> The crux of that solution is the middleware:
>
> def process_request(self, request):
> state = request.method in ['GET', 'HEAD'] and 'slave' or 'master'
> connection.use_state(state)
>
> Which is same as what I am talking about.
I feel obliged to
On Fri, Oct 17, 2008 at 6:07 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> > I do not understand, when everywhere django tries so very hard in a
> > pragmatic sense to decouple things where it logically makes sense, then why
> > suddenly an ideological outburst of "because we are not violating
Malcom,
Thanks for the well-explained response. It's a bit more complicated
than that though as this is only an issue if the field uses a UNIQUE
index. It is an issue up through the latest and greatest stable MySQL
(tested on 5.0.45 and no bug fixes at MySQL up through 5.0.67) and "./
On Fri, Oct 17, 2008 at 7:10 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> To reiterate, I am proposing: "avoid, and if not possible, document" for DB
> updates in GET, are you really saying you are against this? Is your logical
> position "encourage" or "don't care/document"?
To reiterate, I
On Fri, Oct 17, 2008 at 4:03 PM, James Bennett <[EMAIL PROTECTED]>wrote:
>
> On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> > Either this becomes a django standard, every code that might update
> database
> > on GET doing something like:
> >
> >
On Wed, Oct 15, 2008 at 6:38 PM, Jesse Young <[EMAIL PROTECTED]> wrote:
> * Existing apps might rely on it being a function. But it's not
> documented anywhere, so it doesn't seem like apps should be using it
> directly.
I don't know about *should*, but some apps *are*[0]. This would break
On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Either this becomes a django standard, every code that might update database
> on GET doing something like:
>
> connection.use_master()
> try:
> ... # something that updates db
>
On Wed, Oct 15, 2008 at 9:25 PM, bo <[EMAIL PROTECTED]> wrote:
>
> It seems that what you may want is something like
>
> http://softwaremaniacs.org/soft/mysql_replicated/
The crux of that solution is the middleware:
def process_request(self, request):
state = request.method in
Good news.
I'm sure there are tickets for this but I see a lot of breakages when
grouping fields into fieldsets. Labels in particular tend to be oddly
spaced and SELECT's often wrap to a different line to their label.
On Oct 16, 9:35 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Thu,
13 matches
Mail list logo
