Code

Opened 8 years ago

Closed 6 years ago

#2809 closed defect (invalid)

MS SQL Server: Problem with User's history in Admin interface

Reported by: Rockallite Owned by: nobody
Component: contrib.admin Version: master
Severity: normal Keywords: ado_mssql
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Using ado_mssql for db backend, I find that the django_admin_log table created by manage.py install admin command has a problem. The data type of object_id column is "text", which is one of the unsortable data types (text, ntext, image) in MS SQL Server. That makes the user history in Admin interface unusable, throwing expections.

Also it doesn't make much sense if an ID column is of "text" data type. Instead, the data type should be "integer". So the contrib/admin/models.py file has to be modified. I applied the change, and the user history page worked fine.

Attachments (4)

models.py (1.9 KB) - added by Rockallite 8 years ago.
models.diff (776 bytes) - added by Rockallite 8 years ago.
[patch]fix user history in admin interface
models_update.diff (781 bytes) - added by Rockallite 8 years ago.
[patch] This is the correct patch! Sorry I don't have SVN so I had to hand-make the patch…
models_update2.diff (793 bytes) - added by Rockallite 8 years ago.
[patch] Here's another scheme: use CharField type for storing referenced keys in string form. Is it possible for databases other than SQL Server?

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by Rockallite

Changed 8 years ago by Rockallite

[patch]fix user history in admin interface

Changed 8 years ago by Rockallite

[patch] This is the correct patch! Sorry I don't have SVN so I had to hand-make the patch...

comment:1 Changed 8 years ago by mtredinnick

  • Summary changed from User history in Admin interface won't work to MS SQL Server: Problem with User's history in Admin interface

I don't think changing the type of object_id is going to work here. Because it needs to be able to contain the value of the primary key fields from any arbitrary model and because primary keys do not have to be integers, a text field is about the best we can do (storing the string form of the referenced primary key).

So this is still a problem that needs to be solved in some way for SQL Server, but this is not the right way.

Changing the title to reflect what the real problem is.

comment:2 Changed 8 years ago by Rockallite

How about changing it to CharField type which is sortable in SQL Server?

Changed 8 years ago by Rockallite

[patch] Here's another scheme: use CharField type for storing referenced keys in string form. Is it possible for databases other than SQL Server?

comment:3 Changed 8 years ago by mtredinnick

So the obvious problem is that this won't work for the general case because now it fails for anybody with a primary key of CharField(maxlength = 200), for example. Yes, I'm playing Devil's Advocate here, but I'm trying to indicate that we shouldn't be going for lowest common denominator support if it breaks some legimate use cases.

The ultimate fix will change this to something that uses TextField for most databases and something more restrictive (like a CharField) for databases with restrictions like SQL Server. It means some third-party models (nothing in Django core, though) might not work with SQL Server because they require the extra functionality, but that's the one of the costs of making that database choice.

One idea is to make a new field that becomes VARCHAR or TEXT in databases that support sorting on those fields and maps to CHAR(n) on others. However, I'm not totally in love with that idea, either, since it means the programmer can't just use the natural choice (looking at the wider use of that new field): they need to be aware of database differences.

This needs more thinking, definitiely. It's not an easy problem to solve nicely. However, please keep coming up with ideas. They help the process.

comment:4 Changed 7 years ago by Simon G. <dev@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:5 Changed 6 years ago by jacob

  • Keywords ado_mssql added; django_admin_log, object_id removed

comment:6 Changed 6 years ago by adamv

  • Resolution set to invalid
  • Status changed from new to closed

Resolving as invalid, as the SQL Server backend has been removed. 3rd party SQL Server back-ends have solved this bug in various ways (such as using varchar(max) on SQL Server 2005.)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.