Hi Simon,
On Thu, 2006-08-31 at 00:54 -0700, [EMAIL PROTECTED] wrote:
> Hello Djangonauts,
>
> I've found an issue with initial data and SQLite - if any of the fields
> in the initial data has a "%" in it, the import fails. Pysqlite is
> apparently processing the query for string formatting args.
>
> Now, I'm *not* getting this error on MySQLdb, but haven't tested
> postgres/ado_mssql etc. From [1] I think postgres is also affected, and
> would be interested if someone could check this out.
>
> It seems to be quite easy to fix - just do a search and replace for %
> to %% around line 352 in django/core/management.py, in
> get_sql_initial_data_for_model(). However, I'm not sure what the best
> practice for doing RDBMS specific "tweaking/fixing" is - should this be
> implemented in something like db/backends/<db>/base.py?
Probably, yes. We aren't doing that for initial SQL data at the moment,
but it sounds like we are going to need hooks for backend-specific
stuff.
> Nor am I sure how far you want to go in fixing what appears to be a
> pysqlite implementation, uh, wart.
It should be fixed. SQLite is a supported database and very useful in
many cases.
A small meta-argument about the real problem here...
In general, initial SQL data is a real pain to manage and if anybody has
a good idea on a better approach. I would like to avoid building a full
SQL parser in Python for obvious reasons. And yet, the range of things
people can put in initial SQL is pretty broad. There are currently open
tickets for inserting stored procedures and, I think, inserting a small
C program into a field (can't remember if that was sent to me off-list
or is in Trac right now).
I have a memory that there was a problem with just shelling out to the
command-line backend (probably because it was going to be fiddly on
Windows or something), but that may have been an hallucination. Probably
worth looking at again.
Certainly, the initial SQL is a never-ending chase to fix small bugs
with string quoting, SQL portability, Python SQL wrapper portability,
newline handling and problems that we haven't even thought of yet.
Basically, our user-base is very evil... er... creative and each fix has
a half-life of about 15 minutes before somebody comes up with another
broken example. Still, we should fix things as we find them.
>
> Here's a test which should show this up:
[... snip...]
Did this make it into a ticket in the end? I'm unlikely to remember it's
on the mailing list, but if it's in Trac it won't get lost so easily.
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
-~----------~----~----~----~------~----~------~--~---
