Yeah, I'll have a play with doing just that - I'm getting to grips with
Magic Removal at the moment!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-
>(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?)
Could you use properties for this? Properties are in the Magic Removal
Branch I believ
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,
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 othe
Jacob, could you explain why threading.local is heavyweight? On what
platforms is the pure Python implementation used? Windows at least uses
the C implementation.
DaveW: Couldn't you implement this thread local yourself with a very
simple middleware component?
--Ned.
DaveW wrote:
> I see t
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?
--~--~-
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.
ah, looks clever, i like that.
I'll check it when i get into work.
thanks...
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):
...
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)
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.M
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(m
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.c
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 ?
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',
15 matches
Mail list logo
