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.
On Feb 22, 1:52 pm, Collin Grady <col...@collingrady.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
