Well we put that piece of code in test quite soon and see does it help or not. And if some problems arises in big deletes.
Usually it's just something like that you can't delete row from type table if it's in use. Michael Glassford kirjoitti: > > > Jani Tiainen wrote: >> Michael Glassford kirjoitti: >>> Alex Gaynor wrote: >>> >>>> Can you upload it with a .diff extension so we can get proper code >>>> highlighting on trac. >>>> >>>> Alex >>>> >>> Sorry. Done. >> I did a quick look and what I understand now it only supports client >> side on_delete actions (cascade, protect (restrict), set null and set >> default)? > > Yes. > >> I assume that None means not specified on_delete (old way). > > Yes. > > > Could that >> translation to CASCADE or SET_NULL activity made in field construction >> phase? > >> Or is there need to have explicitly define on_delete=None? > > No. > >> Only thing I'm a bit worried is a performance. I have model like >> following (legacy model): >> >> class Device(models.Model): >> name = models.CharField() >> >> class Connector(models.Model): >> device = models.ForeignKey(Device, on_delete=CASCADE) >> type = models.CharField() >> >> class Connection(models.Model): >> connector_1 = models.ForeignKey(Connector, on_delete=CASCADE) >> connector_2 = models.ForeignKey(Connector, on_delete=CASCADE) >> direction = models.CharField() >> >> class Route(models.Model): >> name = models.CharField() >> >> class RouteConnection(models.Model): >> route = models.ForeignKey(Route, on_delete=PROTECT) >> connection = models.ForeignKey(Connection, on_delete=PROTECT) >> >> >> Now I have one device that contains 1000 connectors. Each connection has >> at least 1 connection. And one connection has one route attached to it >> (using RouteConnection). >> >> I want to delete this partical device. >> >> In worst case does system need to traverse over all 999 connections >> before hitting one that says we can't delete device? > > Unfortunately, yes. I realize that the ideal situation is to allow the > backend to handle this if it can, since it can do so more efficiently, > but I didn't think that feature could be ready for the Django 1.2. So I > decided that something is better than nothing and went for a phased > approach. I hope to add backend support in a later version of Django. > > Mike > > > > -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
