Not sure I follow you. You mean overriding the set property of a ForeignKey/IntegerField?
On Feb 23, 6:23 am, "join.toget...@gmail.com" <join.toget...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
