Adrian Holovaty wrote:
> The worst is behind you. :)
Joy! *grin* I feel bad about not getting all the way through a clean
migration and wikiing the steps, but it's been a long couple of weeks
at work and at home! I'll dump some more stuff in today, though, after
I clean up some model stuff. The d
Cool. I really am looking for to it. I have a new project going in MR,
and it's nice! I like all the auth stuff in one place...much simpler.
WRT migrating my older app, though...ick. Do you expect more db-schema
changes of this magnitude before 1.0? I've been in and out of the
rabbit-hole of DML
Adrian Holovaty wrote:
> Yeah, Django doesn't use SELECT * -- the field names are always
> explicitly stated in all Django ORM underlying SQL statements. I add
> fields to my models all the time and never have problems regarding
> column order.
Good deal...I will refrain from fixing them all! *gr
I'm still poking away at db migration issues...this is a new one. The
auth_permission table appears to have been rearranged, field-wise, when
being installed new, vs. the ADD COLUMN DDL that's been suggested on
the wiki:
New install:
sqlite> .schema auth_permission
CREATE TABLE "auth_permission"
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
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
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
I have to concur with Max here. I know it sounds like a pain to migrate
schema changes BY HAND...but trust me, the tools don't help that much.
I'm a DBA in my day job (MS SQL, Oracle, and Postgresql primarily), and
the majority of the problems that occur when developers are trying to
do applicatio
> Of course, that's when you break out and write your own view.
Noted. And I shouldn't complain...it's not like they're exactly hard!
> You shouldn't have to import anything inside a template or generic view
> that either don't already have access to. Also, the "free" access
> didn't affect tem
>>> archive_index is date_list
>>> archive_year is date_list
> But archive_year doesn't return a object list
Yep...I'm actually dealing with that today. It's instead only returning
a list of datetimes that represent the months within that year that
contain objects. (ie, if it's a blog, and you
12 matches
Mail list logo
