On Tue, 2007-08-14 at 06:51 +0200, Lars Stavholm wrote: > Malcolm Tredinnick wrote: > > On Tue, 2007-08-14 at 08:47 +0800, Russell Keith-Magee wrote: > > [...] > >> You will have more difficulty with the Admin application and generic > >> views. Both of these features rely upon the ability to install URLs > >> like: > >> > >> /path/to/object/42/ -> edit object 42 > >> > >> This works fine if you have a single column primary key; however, if > >> you have multiple column primary keys, this isn't so easy to do. To > >> date, every proposed syntax for URL spaces supporting multiple primary > >> keys has either been syntactically ambiguous (e.g., > >> /path/to/object/42,37 - which works unless the primary key has a comma > >> in it), or very inelegant (/path/to/object/42/37/ - which implies a > >> heirarchy where there isn't one). Any proposal for adding multiple > >> primary keys would need to address this very large issue. > > > > Remembering that primary keys are not just integers, so *any* string > > construct you come up with could also be the value of a single primary > > key. (e.g. "42/37/", in Russell's second example, could be a primary key > > value, too). > > I see, not that simple. > > I guess the following idea has been discussed already then: > > Something like... > > /path/to/object/42,37 > > ...where we use a setting like... > > PRIMARY_KEY_SEPARATOR = ',' > > So, if the application needs to use another character to > separate the primary key fields, we could use, for example... > > /path/to/object/[EMAIL PROTECTED] > > PRIMARY_KEY_SEPARATOR = '@' > > ...maybe with a built in restriction of the allowed values > for PRIMARY_KEY_SEPARATOR.
How will you know what your users will enter in the primary key? If it's something like a title or any other arbitrary field, aren't you out of luck? So then you end up looking at escaping mechanisms and it rapidly leads to ugly looking URLs. Periodically, I wonder if it's worth implementing this anyway, just for fun, and then saying if you have multiple primary keys, you can't use those models in the admin. The mechanics are not that hard in most places (it's not entirely trivial, since we can't break existing code that uses the 'pk' attribute on models, etc). Current users would be no worse of. People using the new feature will do it with their eyes open and accepting the consequences of their decision (except therein lies the problem). I haven't gotten as far as pulling the trigger yet, though, since I always have other stuff to do. Regards, Malcolm -- The cost of feathers has risen; even down is up! http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
