On Mon, 2006-09-18 at 22:38 -0700, world_domination_kites wrote: > Thank's for the reply Malcom, > > > > I can't change the table names, since the whole point of this exercise > > > is to make a cheep admin interface to a legacy app. > > Sorry, I wasn't being clear: you don't have to change the database table > > names. If there's a mismatch between what Django wants to call the table > > and what it's really called, you can control the names Django expects to > > find using the db_table attribute on the Meta inner class (see [1]). > > My model was created with inspectdb, so the column and table names are > imported from Oracle (therefor 30 characters or less). I actually only > ran into trouble when I tried to syncdb - it's auth_message and friends > that are producing the troublesome long names.
Aah, ok. Now I understand why you are taking this approach. > I have only looked at Meta inner classes superficially - could they > also know about constraint names of foreign keys? See below for a potential terminology problem. We don't care about the constraint names, for the most part, just the column names. > > > I came up with changing quote_name because it was obviously the > > > interface between base stuff and backend specific stuff . i.e. it's a > > > boundary where Oracle pecularities should be prevented from infesting > > > the Django base. The crazy bit in my first idea was using regex - it > > > smells like a whole bushel of moles, but the boundary seems sensible to > > > me. > > > > > > I have come to suspect that somewhere something has to have > > > repsonsability for knowing what foreign key constraint names mean, > > > since (in Oracle at least) the constraint name itself is to stupid to > > > hold that much information. > > > > I don't understand what you are talking about here. The constraint name > > is just a string for human consumption. It has no implicit meaning in > > any database. > > Yeah sorry, I'll try not to be so abstract / peculiar in the future. I > was being fast and loose with the "assignment of responsability" object > modeling heuristic, where the "responsability" was conveying usefull > information about what constraints are, and it is either being assigned > to the constraint name, or somewhere else. > > Oracle uses constraint names as unique identifiers (and references) in > it's data dictionary. See here: > > sql = """ > select > UC.TABLE_NAME this_table, > UCC.COLUMN_NAME this_col, > UCC2.COLUMN_NAME that_col, > UC2.TABLE_NAME that_table > from > USER_CONS_COLUMNS UCC, > USER_CONSTRAINTS UC, > USER_CONS_COLUMNS UCC2, > USER_CONSTRAINTS UC2 > where UCC.CONSTRAINT_NAME = UC.CONSTRAINT_NAME > and UC.CONSTRAINT_TYPE = 'R' > and UCC2.CONSTRAINT_NAME = UC2.CONSTRAINT_NAME > and UC2.CONSTRAINT_TYPE = 'P' > and UC.R_CONSTRAINT_NAME = UC2.CONSTRAINT_NAME(+) > and UCC.TABLE_NAME = '%s' > """ % (table_name) > > (that works in django.db.backends.oracle.get_names(), by the way.) In normal SQL terminology a constraint is a restriction on a column. It could be to bind it to always refer to another table's and column (i.e. a foreign) key or the other standard things (trying to establish my baseline, not teach you to suck eggs). It just happens that you can name constraints, but you don't have to (in which case, the database server may or may not give it an internal name). Constraint names are really only useful for debugging (they pop up in error messages when you really screw up) and sometimes if you are tweaking a manually created index (on some databases; haven't done much Oracle low-level optimisation work, so I'm not sure of all the possibilities there). Your query above looks like you are just doing joins on columns from tables. Are you saying that some of those things in the "from" clause are not actually tables or views? I've done a fair bit of Oracle database programming and haven't ever come across that, since it's always seemed like Oracle used constraints just like every other database: as a restriction condition on columns. Under that (traditional) terminology, Django doesn't care what the constraints are called, or even if they have names, because it doesn't ever refer to them explicitly. The database enforces the constraints and lets you know when you mess up. However, Django does know about the column names for foreign key references, obviously, since it needs them to construct queries. So are you really talking about the names for the columns that happen to be foreign keys, or are we in a non-standard corner of Oracle land that I haven't stumbled into before? (I'm willing to believe either option; Oracle never ceases to surprise me.) > It's not implicit meaning, but it is more than "just human > consumption". > > <snip> > > > > Am I right to think that "quote_name" should have responsability for > > > knowing what constraint/table/column name to use. > > > > No, it shouldn't. All that function does is turn a string (which could > > be a table name or column name) into something that can be passed to the > > database. It is not given any context for that, just the string to > > convert. At the moment, it pretty much just wraps quotes around things > > in case there are spaces in the names. > > I can see that quote-adding is _what_ it does, but I figured the reason > _why_ is because individual backends have their own DDL dialects, and > the string-fiddeling to turn them into acceptable > column/table/constraint names is potentially different for different > backends. > > If Oracle required major fiddeling - to the point of replacing one > string with a completely different one - then the db.backend.oracle > version of quote_name might be the place to do that. Modulo the fact that you can't tell whether it's a table name or column name you are quoting, your understanding is correct. You'll never get a constraint name passed into quote_name(), since we never need to refer to those; only column and table names. Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
