Seems you could just use an IntegerField and do it yourself, instead
of expecting django to adapt itself to your bad db design :)

On Sat, Feb 21, 2009 at 5:16 PM, Adys <adys...@gmail.com> wrote:
>
> I see what you mean. I agree to an extent - data needs to stay as
> clean as possible. But this isn't the goal in every situation, and
> doesn't always mean that data is erroneous - it can simply be lacking.
>
> Simplified use case:
> I've got for example a table that contains foreignkeys to another
> "additional_names" table no longer maintained publicly. What I want to
> do in this case is use the few hundred rows I gathered from the last
> public versions, and leave the other ones blank. That way, in my app,
> I can display "This object has an additional name, but I don't know
> which". Having listings like that allows me to present data that would
> need post-update manual work, should there ever be enough references
> to a specific lacking row in additional_names to figure it out and
> stub it properly.
>
> When nulling out the foreign keys is an option, I already do that,
> it's not a problem. The problem hits when I have to keep the fkey IDs
> intact.
>
> On Feb 22, 1:48 am, Killian <killia...@gmail.com> wrote:
>> Sorry for the previous one, accidentally pressed alt-s
>>
>> What I meant to say was: as far as I can see your problem is mostly covered
>> by faulty db-design or maintenance, which is not something django should
>> cover in my opinion, it seems logically you do a cleaning of your database
>> to set all non-existing foreignkeys to NULL.
>>
>> 2009/2/22 Killian <killia...@gmail.com>
>>
>> > Hi
>>
>> > 2009/2/21 Adys <adys...@gmail.com>
>>
>> >> Hi there
>>
>> >> I've been thinking for the past couple of days of a simple "lazy"
>> >> ForeignKey design (or whichever name would fit better). It's something
>> >> I've tried really hard to find in Django, unsuccessfully. Some
>> >> explanation first...
>>
>> > Lazy is imho not a decent name indeed, 'lazy' usually means relationships
>> > aren't fetched prematurely (foreignkey object isn't fetched automatically),
>> > which django does by default if I'm not mistaken.
>>
>> >> I tried to get some background on django-users, cf
>> >>http://groups.google.com/group/django-users/browse_thread
>>
>> >> /thread/caec53feb0ddb43a#
>> >> To make it short: My project reuses imported data. This data is *very*
>> >> faulty and a lot of ForeignKeys point to deleted/non-existing rows. I
>> >> can't afford checking integrity constantly (cf link).
>>
>> > As far I c
>>
>> >> A lazy ForeignKey would assume the data is valid, and return
>> >> "something else" if it's not. I'm not sure what the best value
>> >> returned would be. It could be a row with placeholder/default values,
>> >> it could be an exception, etc. I haven't worked deeply with Django's
>> >> codebase, I'm unsure about design details.
>> >> The idea here is to be able to offer something "valid or unknown". I
>> >> hope I'm not too unclear...
>>
>> > First of all, imho this isn't about "lazy", lazy usually means
>> > relationships aren't fetched prematurely (foreignkey object isn't fetched
>> > automatically), which django does by default.
>>
>> > Secondly, the NULL value in databases is actually defined originally as
>> > Unknown, so it seams normal in your situation to default to None if your
>> > relationship is undefined (and allow null=True in your model).
>>
>> >> I'm sure there's a better solution - I have yet to find it - but I
>> >> would first like to hear feedback on a feature like that. If you feel
>> >> it's a good idea I'm interested in working on it. If you feel
>> >> otherwise, well... I'm still looking for a better suggestion.
>>
>> >> Cheers
>>
>> >> JL
> >
>



-- 
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 django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to