> What is the best way to dispatch to a method based on both HTTP method *and*
> a URL?
Basically you've found it, and it is a clean way to code. However you
have to consider calling get_myresource() from post_myresource(), as
you would probably do if the POST has errors. Typically manipulators
I'm on it!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROT
No problem...I completely understand. My guess was indeed exactly
that...most development has been already IN M-R for so long, that all
the issues have been caught and fixed bit-by-bit, over a long period.
I'll go add the SQLite column rename workaround now, and get started on
testing other fixes
On Mon, 2006-04-24 at 01:23 +, Alexis Smirnov wrote:
> Some of the URLs in my django application are addressable by both POST
> and GET requests. This results in the code like this:
>
> urls.py:
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> (r'^myapp/myres
Some of the URLs in my django application are addressable by both POST
and GET requests. This results in the code like this:
urls.py:
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^myapp/myresource/$', 'myproj.myapp.myresource'),
views.py:
...
def myresourc
On 4/23/06, Ken Kennedy <[EMAIL PROTECTED]> wrote:
> Hey all...I promise, I'm not trying to start trouble, but has anyone
> actually TESTED the "rename core database tables" DDL against anything?
> Not just for syntax validity (which, as of right now, I know it fails
> with SQLite), but also a com
On 4/23/06, Ken Kennedy <[EMAIL PROTECTED]> wrote:
> The primary point would be that the
> http://code.djangoproject.com/wiki/RemovingTheMagic description:
>
> "We've renamed a bunch of the core Django tables. To upgrade in MySQL
> and SQLite, execute this SQL in your database:
>
> ...
>
> ALTER T
Hey all...I promise, I'm not trying to start trouble, but has anyone
actually TESTED the "rename core database tables" DDL against anything?
Not just for syntax validity (which, as of right now, I know it fails
with SQLite), but also a comparison of post-migration DDL to "start
clean" DDL (ie, are
> You are correct, sqlite doesn't fully support ALTER statements. See
> http://www.sqlite.org/omitted.html for a full list of unsupported features.
Oh, I know. I was trying to be extra conservative and nice, and give
someone a way out...*grin*
The primary point would be that the
http://code.djan
You are correct, sqlite doesn't fully support ALTER statements. See http://www.sqlite.org/omitted.html for a full list of unsupported features.Ken Kennedy <[EMAIL PROTECTED]> wrote: I'm trying to upgrade a small install in place, and note that the"Rename core database tables" scripts do a couple of
On 3/8/06, limodou <[EMAIL PROTECTED]> wrote:
[...]
> Because formfield doesn't has a verbose_name property. So I want to
> ask why there is no verbose_name in FormField __init__() function. I
> think if there is verbose_name, so create a form code will be easier.
I would also be interested in th
I'm trying to upgrade a small install in place, and note that the
"Rename core database tables" scripts do a couple of column renames to
django_content_type near the end. Has this been tested with SQLite3? It
fails for me, and with a quick ref to the SQLite docs, I don't think it
even supports col
Now works for me.
Many thanks, this was the last thing I needed to go live with a new
Magic LiteĀ application. :)
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
13 matches
Mail list logo
