On Sat, 2006-08-05 at 08:15 -0700, David wrote:
> Django-0.95, with Oracle backend patch (latest: 3496?) applied.
> Python 2.4 on Linux
> Oracle XE and Oracle 10gR2
>
> When I try to run syncdb using the Oracle backend, I reliably get the
> following error (last part of traceback only, let me know if I should
> post the whole traceback):
>
> File "django/db/backends/oracle/base.py", line 70, in execute
> return Database.Cursor.execute(self, query, params)
> cx_Oracle.DatabaseError: ORA-00911: invalid character
>
> I get this error whether I configure to use an Oracle XE (10g) instance
> or Oracle 10gR2 instance. If I do a "sqlall" and run the resulting file
> using sqlplus, I don't get this error. (I DO get some
> identifier-too-long errors, but if I edit the output of sqlall, those
> go away.)
>
> The main question is: How can I get syncdb to work without tracing
> back?
Good question. As you probably realise, the Oracle backend is pretty
much unmaintained at this point, since the requirements for working on
it are pretty hefty (starting with "1. install Oracle"). So be aware
that you are currently the world's expert on the Oracle backend. You've
applied the patch and made it run that far. That being said, if you want
to put in the work to get this up and running, please ask as many
questions as you need to. We may not be able to help on all things
Oracle, but we can at least give you the background and motivations for
why things are done as they are at the moment and help you apply your
Oracle-specific knowledge to getting a solution.
You are going to have to put some debugging prints into
db/backends/oracle/base.py and possibly look at what (if any) character
set assumptions the cx_Oracle module and/or your Oracle instance are
making. My first step would be to look at what "query" and "params" are
just before the above traceback (wrap a try...except block around the
return statement and only print in the except portion and then re-raise
the exception).
I dimly remember having character set problems with Oracle in the past
when talking through the Python interface, but the specifics escape me
at the moment. I don't have an Oracle install around the test anything
on at the moment, either.
> A second question: What are my options with respect to long
> identifiers? So far, it's just in the constraint names. For example:
>
> ALTER TABLE trips_aircraft ADD CONSTRAINT
> type_id_referencing_trips_actype_id FOREIGN KEY (type_id) REFERENCES
> trips_actype (id);
>
> The constraint name (optional in Oracle) tries to be
> type_id_referencing_trips_actype_id but Oracle has a maximum allowed
> length of 30 characters.
Grrr. It's the 21st century. Why can't databases handle things longer
than this? Some of Oracle's restrictions and oddities are really bizarre
for a database that is used in so many data-critical situations. :-(
I have been trying really hard not to just nuke the constraint names.
When you do violate a constraint, having a useful name in the error
provides some information about where to look for the problem (since
it's always going to be an accidental violation and never where you were
expecting the problem). Anonymous (backend generated) names make
debugging harder, since you have to know how to track back from the name
to the constraint to the table(s) it applies to and that is
backend-specific.
Moving the name generation into the backend is starting to feel more and
more attractive. Or maybe just saying "most unlucky" to the debugging
case and using anonymous names everywhere we can. I really hate the last
option, though, since helping people debug problems is a reasonable
courtesy.
For now, if you want to hack on the source for your initial
testing/debugging, have a look in django/core/management.py around line
206. There's a line that says
r_name = '%s_refs_%s_%x' % (r_col, col, abs(hash((r_table,
table))))
(it's the only place we use hash() in the code in that file, so search
for that word). Change this to anything you like that will make your
backend happy. That will tide you over until we can get a more
reasonable solution in place.
Good luck,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users
-~----------~----~----~----~------~----~------~--~---
