On Mon, 2006-09-18 at 01:42 -0700, world_domination_kites wrote: > Hi, > I'm trying to get the oracle backend to work properly. Have made some > progress, but now I need some guidance on The Django Way. > > Oracle seems to have a 30 character limit for constraint names, table > names, and column names. When I syncdb, django trips up with an ALTER > TABLE ADD CONSTRAINT using a constraint name that's too long. I traced > the problem back to _get_sql_for_pending_references, and am not sure > how to proceed.
Constraint naming and creation is a work in progress at the moment. There are sides to the problem: (1) Having somewhat sensibly named constraints so that error messages make sense, and (2) Fitting in with all the varied restrictions that databases variously impose, such as Oracle's ridiculous 30 character limit (dear Oracle, 1985 called and they want their maximum string length back), MySQL's 64 character limit and "uniqueness across all constraints in the database" limit, and so forth. This is further complicated by the fact that we sometimes create the constraints inline (via "REFERENCES ..." clauses in the table creation statement) and sometimes, due to forward references, as "ALTER TABLE..." statements. When we are removing constraints, we don't always get it right. The solution is to move a lot of this stuff into database-specific backends, rather than trying to do it all in management.py. This isn't rocket science, but it is a little bit intrusive and I (or anybody else) haven't actually got around to doing it yet. Soon(-ish), this will be fixed, because it's currently like playing whack-a-mole: fix one bug and another one pops up somewhere else. > Should I hack the Oracle 'backend.quote_name' to make short names? I'm > not realy familiar with Django, that sounds like handy sort of method, > it might be called all over the place, I don'nt want to break lots of > things. Should I do something stupid like "munge when matches > *_referencing_*"? how would a Django guru do it? For table names and column names, you can usually get away with just using names that are short enough in your Python code (you can control almost every table and column name if you don't like the automatic choices), I would think. Changing quote_name() is also not a crazy solution and might be worth investigating for true portability. I would guess that sort of use is one reason it's been made backend-specific. If you come up with a patch for that (it's likely to be pretty much localised to db/backend/oracle/, I would think), it would be a useful addition. As an aside, the one hole in the claim that you can control all table names is many-to-many intermediate tables. There is presently no way to specify the name for such a table and, again, it's an enhancement that will be implemented at some point, no doubt, because it's also necessary for true legacy database support. 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 -~----------~----~----~----~------~----~------~--~---
