Malcolm Tredinnick wrote: > 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
Well, all of the databases I've been looking at are sort of professionally built, and don't really use arbitrary strings for any primary key field. The usual case is a combinations of integers, and in some cases a combination of integers and simple/short strings, like unix usernames, invoice number characters and integers mixed in a single string field, and such. One could even assume that there's no strange characters within the primary key field. I've been working with RDBMSs for a good while, and I've never seen any arbitrary-string-in-primary-key-field requirement, no commas, no dots, no semicolons, nothing like that. It's simply bad practice to have primary keys like that. > 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. I'm not really looking for the arbitrary string case, and definitely not putting stuff like a title in the primary key. It's a question of a primary key for an RDBMS, a couple of best practice limitations fits in nicely, e.g. integers (mostly) and short strings, like order number as a string, invoice number as a string, stuff like that. > 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. Yes, well, I think it might be worth the effort. Imagine how many legacy databases would benefit from a user interface built with django, web or native. However, I do believe that the admin interface should be an integral part of this, it's essential in getting your application up and running quickly. Just my 2c worth /Lars --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
