You completely misread the tone of the email - that *was* my pointer for how to do it - instead of trying to shoehorn it into ForeignKey where it doesn't belong, just use an IntegerField, possibly with model functions to do the querying (which could be made properties to act like fields) to get the info from the other table and return the default you want if the other row is missing.
On Sun, Feb 22, 2009 at 2:51 AM, Adys <adys...@gmail.com> wrote: > > Except... I'm not expecting anything. > > I'm going to work on this regardless, I'm just proposing to share my > work in exchange for a few pointers here and there. Sarcasm, and > blaming the user, is a very tasteless way of saying no. > > > On Feb 22, 10:52 am, Collin Grady <col...@collingrady.com> wrote: >> 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
