Malcolm Tredinnick wrote: > On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote: > [...] > >>> Maybe be you mean transparently. If so, I think this is a requirement, >>> too, but it's not a problem. We know when the ForeignKey field is >>> specified which model it refers to, so we can include the correct number >>> of database columns at table creation time. We have perfect information >>> when we create the table, which is where this differs from any generic >>> relations. >>> [...] >>> >> Does that apply even to recursive (reflexive) relationships, when the >> related model must be specified by name rather than by reference? I >> don't know enough about the internals to be clear on that, but it seems >> like it could be problematic. >> > > It needs to be taken into account, but it's certainly solvable and not > an obstacle to success. There are two solutions available: > > (1) Postpone creating the first table until we have read the second > table so that we know the number of columns. This isn't too hard, > although it means you end up making two passes over some classes' > internals in some cases. But table creation is such a rare event and the > Python code is so fast that it's easily affordable. We're not talking > about something changing from 15 minutes to 20 minutes or anything. > Sure. Perhaps it's not common terminology: by "recursive" I meant a self-referential relationship, though now you mention it I see that the same issue can occur if the order of model definitions is sub-optimal. > (2) The poor-man's approach is "ALTER TABLE", which is a small-ish > change, but butt ugly. I prefer the former solution, but the this is the > silly drop-in I've got at the moment just to make things possible to > develop with. > I can see why, from a purist point of view, you'd rather not use it. Doesn't mean it couldn't be useful as a first implementation, though. > Realise that the reason we have string-ified forwards references is to > avoid the need for circular imports. But at some point we'll end up > importing everything anyway and then we can go and look at the number of > required columns. This is why forwards references work in the first > place -- at a later time we go back and fix up the internal references > to point to the Python objects in question. We can change table creation > to operate similarly. It's not that hard. > > I understand that. I just don't have the smarts to be able to help right now, but thanks for the explanations.
regards Steve --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
