On 12/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> I can see two fundamentally different approaches to this problem:
>
> 1. Deal with it at the ORM level, perhaps by getting MySQL to emulate
> timezone aware datetimes by using two dB fields - a naive datetime,
> and a varchar containing
James Bennett wrote:
>
> It used to work in older versions of Django. Right now it is not
> supported, and it is probably quite dangerous to the integrity of your
> data to rely on things which accidentally "sort of work" due to the
> remains of the legacy system. Again: this is not currently sup
James Bennett wrote:
>
> Django does not currently support any form of subclassing or
> inheritance for model classes. Please search the archives of this
> list, the django-developers list, or the Django Trac instance if you
> would like more information on this topic.
I have always read that Dj
Marty Alchin wrote:
> I've come up with a considerably different approach to this, which
> offers more flexibility, and also solves a problem I've had when it
> comes to ManyToManyField. Basically, instead of dealing with signals,
> and worrying about pre/post and whether or not you can prevent st
On Sep 11, 1:20 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>
> I'm hoping to look into revamping some ManyToMany stuff during the
> sprint, so it's possible that something like this might be made easier
> after that. Note that the words "hoping", "possible" and "might" all
> combine to indicate
On Sep 11, 1:20 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>
> I'm hoping to look into revamping some ManyToMany stuff during the
> sprint, so it's possible that something like this might be made easier
> after that. Note that the words "hoping", "possible" and "might" all
> combine to indicate
In one of my apps, I have the need to track changes to M2M objects, and
run some code when one of them gets added/deleted/cleared. I looked for
a way to do this, and could not find any: the M2M Manager is created
dynamically, thus I cannot extend its class or use a custom one; and
since it can
On Aug 31, 2:13 am, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> The change he proposes would also break normal saving :)
>
> f = Foo(id=3, name="some new name")
> f.save()
>
> Would start throwing an exception since the row already existed but it
> would be trying to insert.
There's also an oppos
