> Be aware, though, that there are lots of SQL constructs
> (including a lot that crop up in stored procedures) that are
> not handled correctly in the initial SQL parsing. For
> backend-specific stuff, that's a small bug. For the more
> general initial SQL, it's an unsolvable problem.
Where would I go digging into understanding these limitations
better? It seems to be in
management.py: get_custom_sql_for_model()
Is there anything else I missed? I vaguely remember seeing the
output to some of the manage.py commands come out as colorized.
I couldn't find the code to do that. I don't remember if it just
colorized everything, or if it tried to be smart about parsing
it. However, this seems to be the only place where custom
back-end SQL would cause problems. The rest of the code looks
fairly forgiving.
I did notice while wandering through this code that is should
handle most SQL, assuming that a terminal ";" (followed by
optional whitespace before the EOL) separates statements. This
should be sufficient for defining most stored procedures.
However, I did notice that the regexp for pruning out comments is
a bit lax, as it misses the event where a comment-marker is in a
string:
insert into app_tbl (column_name) values ('has--dashes');
chokes. Granted, it's a tad pathological and fairly obvious to
catch that something has gone wonky, but it would be best to
avoid if possible.
The following two small changes tighten that up a bit to prevent
that error case.
+ comment_re = re.compile("""^((?:'[^']*'|[^'])*)--.*""")
for sql_file in sql_files:
if os.path.exists(sql_file):
fp = open(sql_file, 'U')
for statement in statements.split(fp.read()):
# Remove any comments from the file
- statement = re.sub(r"--.*[\n\Z]", "", statement)
+ statement = comment_re.sub(r'\1', statement)
if statement.strip():
output.append(statement + ";")
fp.close()
It also saves you from re-compiling the regexp for every file.
Not a huge savings, but just a general nicity. :)
> So if you are using complicated SQL in your stored procedures,
> you may need to load it manually.
With the above patch, it seems the only caveat in
back-end-specific SQL would be to ensure that your SP doesn't
have any lines ending with a semi-colon or otherwise it will get
split across execute() calls.
Kosher?
-tim
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
