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.
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. 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. 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. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
