On Tue, 2006-09-19 at 03:18 +0000, world_domination_kites wrote: > 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. Also, i'm new to > Django so am not familiar with previous discussions - sorry if i'm > covering old ground.
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]). You can also control the column names using the db_column parameter when you define your Model fields (see [2]). [1] http://www.djangoproject.com/documentation/model_api/#db-table [2] http://www.djangoproject.com/documentation/model_api/#db-column > 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. > My next idea was just to let Oracle have it's system generated > constraint names, and then COMMENT ON COLUMN TABLE_NAME.COLUMN_NAME IS > 'foreign key referencing foo.bar'. I haven't looked into Django error > messages, but suspect this would lead to some work there. Also, it > would not work for columns that are both a foreign key and have a check > constraint. Likewise, it further confounds compound-key issues. So, > this idea might not be so hot. You are over-complicating things here. My reference to wanting reasonably-named constraints for debugging purposes is just in case the database spits out an error message. Django makes no effort at all to interpret the error messages from the database. And, as I mentioned, always having human readable constraint names is not going to be possible in any case (for all databases), so it's not really something to worry about. It was a nice pipe dream once. > The next thing to pop into my head was an Oracle backend specific > lookup table. That made my bad idea detector CLANG! so I have to move > on. > > The next idea to ask the django.model meta class to know it for me. I > glossed over the meta inner class in the Django tutorials, havent ever > had anything to do with it. Is there colaboration between model.meta > and the error system, or is the DB spewtem passed allong verbatem? > > 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. > Where else might this > be done? If this is the best interface, Oracle backend could be more of > a 'quote_or_lookup' sort of 'quote_name', however it's stored. If we > sacrifice lovely raw database error messages for Oracle (serves you > right), is there a way that dosn't affect any of the dependancies > within django. Like, if quote_name parameter is Oracle safe, don't mess > with it, but if it's too long, replace with a short hash (unique > gibberish). This would require some sort of reserved character to > distinguish user specified gibbberish names from hashes, and possibly > the only other thing would be to fiddle the self-documenting thingy in > contrib.admin so it maps the inconviently long sensible names to the > silly short ones. Contemplating gibberish column names makes me feel > bad, so this isn't right either. Perhaps I should just make my > db.oracle.quote_name do "replace if parameter is in a key in the dict > of known kludges, then do a normal quote name", then secretly maintain > the shamefull dict of known kludges until someone else finished > db.oracle. I suspect you are trying to bite off far too much at once here. If it were me, I would work out how I might be able to make quote_name() produce sufficiently short strings when it needs to. Then see if anything else needs tweaking. A lot of the stuff you are worrying about (admin docs, etc) have nothing to do with the database: they are constructed from introspecting the Python code. For your immediate purposes, though, look at db_table and db_column options. For retrofitting models to a legacy database, they are usually the right things to use. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
