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.
I have only looked at Meta inner classes superficially - could they
also know about constraint names of foreign keys?
> > 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.)
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.
<snip>
> I suspect you are trying to bite off far too much at once here. If it
wouldn't be the first time :)
> 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.
OK, I will do that. I can only spare an hour here and there, so it
might take me a few days.
> 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.
I know that - but my python code was created by inspecting the database
in the first place. I still suspect the python code should (optionally)
know about constraint names - will read up on Meta inner classes.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
