On Tuesday 31 January 2006 21:38, Adrian Holovaty wrote:
> Nice explanation, Luke! I've added it to the FAQ.
I noticed it in django-updates, and thought "that sounds really
familiar"!
Luke
--
"Ineptitude: If you can't learn to do something well, learn to enjoy
doing it poorly." (despair.com
On 1/31/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> The Django ORM basically assumes a third normal form database design.
> It half enforces this by adding a primary key to every table (if you
> don't specify one yourself), and only allows one field to be a primary
> key in the class definition.
On Tuesday 31 January 2006 16:59, kggroups wrote:
> I'm considering building my next web app in either Django or Rails
> because I'm sick of php. Before I jump in though, I was wondering
> how django handles multicolumn keys.
If you need to, you can specify constraints using unique_together - se
Aany "model" can be included in the admin interface as long as you
include a META subclass inside of it with the admin attribute defined:
class Tagged(meta.Model):
user = meta.ForeignKey(User)
site = meta.ForeignKey(Site)
tag = meta.ForeignKey(Tag)
class META:
admin=meta.Adm
wow. that is pretty simple. thanks for the response.
i'm guessing adding additional attributes to the Tagged class would not
be a problem? for example, a date, etc?
Would even the Tagged class have an admin form prebuild?
Something like this for your models:
class User(meta.Model):
name = meta.CharField()
class Website(meta.Model):
url = meta.CharField()
class Tag(meta.Model):
name = meta.CharField()
class Tagged(meta.Model):
user = meta.ForeignKey(User)
site = meta.ForeignKey(Site)
ta
6 matches
Mail list logo
