Re: Model Basics
On 2/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Yeah, we talked about this on Sunday at the Django sprint. The > tentative plan is to introduce a CurrentUserField which is > special-cased in the admin logic. How would this be handled in user code? How would Manipulators deal with these, ie, would Manipulators have to start taking request.user in addition to request.POST? (I'm assuming you've put thought into how this will effect the proposed changes to Automatic Manipulators, as well?) In particular, I have a couple of Models that are created updated during the save() of other Models (ChangeLogs and Changes) and I realize this is a special case, but is there any good way to have have CurrentUser information available to something like the save() without tying it to only the Admin (ie, still allowing custom forms or shell-based modifications)? (On a side note, I could use the ability to have custom non-Model-Fields (ie, not persisted in the database, only used in the save() ChangeLog generation) in the Admin, is there an existing way to do this?) -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Model Basics
On 2/28/06, DaveW <[EMAIL PROTECTED]> wrote: > I see that ticket #1268 has been closed as WontFix - threadlocal is > felt to be to heavyweight a solution. Unfortunately, some mechanism for > this is going to be needed for Django to be used in many corporate > environments - has anyone had any other thoughts about how to implement > this? Yeah, we talked about this on Sunday at the Django sprint. The tentative plan is to introduce a CurrentUserField which is special-cased in the admin logic. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Model Basics
I see that ticket #1268 has been closed as WontFix - threadlocal is felt to be to heavyweight a solution. Unfortunately, some mechanism for this is going to be needed for Django to be used in many corporate environments - has anyone had any other thoughts about how to implement this? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Model Basics
Thanks, I wasnt sure from the documentation if subclassing would do a "inheritance" DB thing like many ORM tools support, or simply combine the two classes as I was hoping for.
Re: more model basics - mny to many's
ah, looks clever, i like that. I'll check it when i get into work. thanks...
Re: more model basics - mny to many's
On Feb 14, 2006, at 9:55 AM, gizo wrote: Each Song can have Many Player/Instrument combinations (where each musician could play any instrument, in theory) Give this a shot:: class Musician(meta.Model): ... class Instrument(meta.Model): ... class Band(meta.Model): ... class BandMember(meta.Model): band = meta.ForeignKey(Band, edit_inline=meta.STACKED) musician = meta.ForeignKey(Musician) instruments = meta.ManyToManyField(Instrument) (Something pretty similar to this is what we use for the band database on lawrence.com, and it works well). Jacob
Re: more model basics - mny to many's
wont that just give me: Each Song can have many Instruemtns Each Song can have many Musicians? what I want is: Each Song can have Many Player/Instrument combinations (where each musician could play any instrument, in theory)
Re: more model basics - mny to many's
what do you need the table songInstrument for? i´d suggest using a many-to-many relationship ... see http://www.djangoproject.com/documentation/model_api/#many-to-many-relations hips class song(meta.Model): title = ... duration = ... instrument = meta.ManyToManyField(instrument) musician = meta.ManyToManyField(musician) def __repr__(self): return self.title() class META: admin = meta.Admin() patrick > > Hiya. > I am not a web developer, okay, just trying to do a band website (so > take it easy on me, please ;) > I am having trouble with my models. > > I have the following: > > class musician(meta.Model): > ... > class instrument(meta.Model): > ... > class song(meta.Model): > .. > class songInstrument(meta.Model): > song = meta.ForeignKey(song, edit_inline=meta.TABULAR, core=True) > instrument = meta.ForeignKey(instrument) > musician = meta.ForeignKey(musician) > def __repr__(self): > return "%s, %s, %s" % (self.get_song(), self.get_musician(), > self.get_instrument()) > class META: > admin = meta.Admin() > > So each song has many musicians playing many instruments (ie. Jerry > might have played drums and bass and read Chaucer in a particular > song). This is great, and when I add a song in the admin section, I can > add all this detail, but when I look at songInstrument in admin, there > are no entries?? > > Can anyone tell me: > a) where have I gone wrong? > b) is there an easier way to set up these (and similar) models? > > thanks, > and keep up to good work, django ist fun >
more model basics - mny to many's
Hiya. I am not a web developer, okay, just trying to do a band website (so take it easy on me, please ;) I am having trouble with my models. I have the following: class musician(meta.Model): ... class instrument(meta.Model): ... class song(meta.Model): .. class songInstrument(meta.Model): song = meta.ForeignKey(song, edit_inline=meta.TABULAR, core=True) instrument = meta.ForeignKey(instrument) musician = meta.ForeignKey(musician) def __repr__(self): return "%s, %s, %s" % (self.get_song(), self.get_musician(), self.get_instrument()) class META: admin = meta.Admin() So each song has many musicians playing many instruments (ie. Jerry might have played drums and bass and read Chaucer in a particular song). This is great, and when I add a song in the admin section, I can add all this detail, but when I look at songInstrument in admin, there are no entries?? Can anyone tell me: a) where have I gone wrong? b) is there an easier way to set up these (and similar) models? thanks, and keep up to good work, django ist fun
Re: Model Basics
2006/2/12, ChaosKCW <[EMAIL PROTECTED]>: > 1) can you access the session user object from the model _pre_save no see http://code.djangoproject.com/ticket/1268 though > 2) can you subclass a model. yes see the docs (either on www.djangoproject.com/documentation or the wiki on code.djangoproject.com) -- Brice Carpentier aka Br|ce
Re: Model Basics
PS the project and app level DB would also allow for creater scalablity and better seperation of concerns. One last question, is it possible to add a glboal hook into the ORM layer ala SOX requiremens i the USA. To proide an audit of any transaction ?
Model Basics
Hi
I would like to ask about three things:
1) can you access the session user object from the model _pre_save
2) can you subclass a model.
3) app level db
Example of what I want:
class Audited_Model(meta.Model):
audit_created = meta.DateTimeField('Date and Time this account
was created', auto_now_add=true)
audit_modified = meta.DateTimeField('Date and Time this account
was created', auto_now=true)
audit_user = .
def _pre_save(self):
audit_user = session.user
class PFS_Client(Audited_Model):
""" This is the current client record and holds all there data
"""
name = meta.CharField('Account Name', maxlength=50,
help_text='Enter the name used to identify this account')
description = meta.TextField('Account Description',
maxlength=200, help_text='Enter a description of this account')
client_type = meta.
for the app level db, it would be most usefull to have both an app
level db and project level db. The project level db could be used for
all things shared across apps while the app db could specific to that
application. This prevents having to "namespace" tbale with a prefix.
Thanks,
