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