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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
