Well he'd have to use an IntegerField, not a ForeignKey, but the same
idea applies - he can do his own validation/etc in the property
handlers.

On Mon, Feb 23, 2009 at 7:27 PM, Jerome Leclanche <[email protected]> wrote:
>
> Sounds like that wouldn't work. Django fails on __init__ with invalid
> foreignkeys.
>
> On Tue, Feb 24, 2009 at 3:24 AM, [email protected]
> <[email protected]> wrote:
>>
>> On Feb 22, 10:30 pm, Adys <[email protected]> wrote:
>>> Not sure I follow you. You mean overriding the set property of a
>>> ForeignKey/IntegerField?
>>>
>>> On Feb 23, 6:23 am, "[email protected]"
>>>
>>> <[email protected]> wrote:
>>> > What about something like a property()? The set method would act like
>>> > normal, but the get method would have some extra logic built into it
>>> > that would take care of everything.
>>
>> Something like the following:
>>
>> _other=models.ForeignKey('Other')
>>
>> def _set_other(self, o):
>> _other=o
>>
>> def _get_other(self):
>> try:
>> return _other
>> except Other.DoesNotExist:
>> return None
>>
>> other=property(_get_other,_set_other)
>>
>> When someone tries to access "other", it will call the _get_other()
>> method automagically, so you can have whatever logic you need in there
>> without forcing anything but the model to deal with it.
>> >
>>
>
>
>
> --
> Adys
>
> >
>



-- 
Collin Grady

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to