Re: Problem with history view in admin page

> > I'm not sure what you're asking me. "Blockers" of what? > I meant, for sure we know that the backend can switch the lookup to the hidden column (from the original column) by overriding - 'field_cast_sql(self, db_type):' The backend also needs to execute the SQL to create the hidden column

Re: Problem with history view in admin page

On Thu, Jan 7, 2010 at 2:02 PM, Mario Briggs wrote: > Russ, > > The indexing that Oracle is supporting is 'index-on-expression'. DB2 > also supports that, but it isnt enabled for character long columns, > since they hadnt had a request for that. I talked to the DB2 server

Re: Problem with history view in admin page

Russ, The indexing that Oracle is supporting is 'index-on-expression'. DB2 also supports that, but it isnt enabled for character long columns, since they hadnt had a request for that. I talked to the DB2 server folks about these use-cases and they have agreed to support this via

Re: Problem with history view in admin page

> The *only* reason that we are even talking about adding this field is > because DB2 can't index on the datatype that is the natural match for > a length-unlimited TextField. > Oracle's indexing imposes an > implicit limit of 4000 characters; that sounds to me like as good a > number as any.

Re: Problem with history view in admin page

On Wed, Dec 9, 2009 at 8:17 PM, Mario Briggs wrote: > I was too harsh on the GenericKeyField. How about GenericKeyField > (length=x). I think the reason i put length in there is obvious, but i > can explain if need be. Well, you may have to, because the reason that it

Re: Problem with history view in admin page

I was too harsh on the GenericKeyField. How about GenericKeyField (length=x). I think the reason i put length in there is obvious, but i can explain if need be. In post #14 on this thread you suggested - " I'm not wild about the idea of having underlying datatypes change based on attributes in a

Re: Problem with history view in admin page

On Thu, Dec 3, 2009 at 12:59 PM, Mario Briggs wrote: > Russ, > > I dont agree to the *it works* theory here - Ian rightly said 'If you > ask me, > anybody foolish enough to use a TextField as a primary key deserves > what they get' and you agreed  'Your comment about

Re: Problem with history view in admin page

Russ, I dont agree to the *it works* theory here - Ian rightly said 'If you ask me, anybody foolish enough to use a TextField as a primary key deserves what they get' and you agreed 'Your comment about foolishness is definitely correct ' Putting it in context, this is in the 'user control area'

Re: Problem with history view in admin page

On Fri, Nov 27, 2009 at 3:22 PM, Yuri Baburov wrote: > Hi Russell, > > On Thu, Nov 26, 2009 at 1:47 PM, Russell Keith-Magee > wrote: >> On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov wrote: >>> Hi Russell, >>> >>> is it possible to

Re: Problem with history view in admin page

On Fri, Nov 27, 2009 at 4:21 PM, Mario Briggs wrote: > Russ, > >> With a different coat of paint, it might be more palatable. A name >> like ShortTextField presupposes the storage implementation, but tells >> you nothing about the appropriate usage. However, a different

Re: Problem with history view in admin page

Richard, > I don't know why a user should have .filter(object_id='1') > fail, as that breaks the ORM abstraction. Maybe that's not what you're > suggesting? I am saying exactly what i am saying. So here's my example that does the same thing in a java ORM // Here's the model @Entity public class

Re: Problem with history view in admin page

Hi Russell, On Thu, Nov 26, 2009 at 1:47 PM, Russell Keith-Magee wrote: > On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov wrote: >> Hi Russell, >> >> is it possible to introduce some new field type >> ShortTextField for that purpose, that will be by

Re: Problem with history view in admin page

On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov wrote: > Hi Russell, > > is it possible to introduce some new field type > ShortTextField for that purpose, that will be by default > `varchar(4000)` on Oracle and DB2 who supports long varchars, and > `text` on other backends like

Re: Problem with history view in admin page

On Tue, 2009-11-24 at 20:54 -0800, Mario Briggs wrote: > Instead we will let users run into errors when they do a '=' compare > of a Django Text type, and then let them ponder whether they need that > column as a CLOB in the backend. Shouldn't something be changing that = into a LIKE (and

Re: Problem with history view in admin page

Russell, > >> Well, Django doesn't make the decision to use CLOB - that's in the > >> hands of your backend. In the same circumstances, SQLite and Postgres > >> use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB' I understand that the decision to what 'Text' should be mapped to is the choice

Re: Problem with history view in admin page

On Tue, Nov 24, 2009 at 7:09 PM, Russell Keith-Magee wrote: > This is a slightly moot point, though; Django defines the admin log > object_id using a TextField, and changing this would be a big > backwards incompatibility. > > Also I believe there's at least one other

Re: Problem with history view in admin page

On Wed, Nov 25, 2009 at 1:25 AM, Ian Kelly wrote: > On Mon, Nov 23, 2009 at 11:00 PM, Russell Keith-Magee > wrote: >> On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs >> wrote: >>> I agree that INTEGER is not the right

Re: Problem with history view in admin page

On Mon, Nov 23, 2009 at 11:00 PM, Russell Keith-Magee wrote: > On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs wrote: >> I agree that INTEGER is not the right choice, but then so too is CLOB. >> How long is this string-serialized representation

Re: Problem with history view in admin page

On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs wrote: >>> > What is stored in this field is a string-serialized representation of > the > primary key value. > << > > I agree that INTEGER is not the right choice, but then so too is CLOB. > How long is this string-serialized

Re: Problem with history view in admin page

>> What is stored in this field is a string-serialized representation of the primary key value. << I agree that INTEGER is not the right choice, but then so too is CLOB. How long is this string-serialized representation going to be? greater than 4000 characters ? Varchar(X) where X is > 4000 or

Re: Problem with history view in admin page

Note Oracle had the same problem: http://code.djangoproject.com/ticket/5087 I can't actually read Oracle but I think the fix involves adding a cast that extracts the first 4000 chars of data from the field for comparison. They override the field_cast_sql method in the Oracle DatabaseOperations

Re: Problem with history view in admin page

On Mon, Nov 23, 2009 at 9:12 PM, Rahul wrote: > Hi All, > > There is a problem reported for history view in admin page. > For history view there is a sql query generated, which trying to do > exact look-up on OBJECT_ID column (LogEntry model, DJANGO_ADMIN_LOG >

Problem with history view in admin page

Hi All, There is a problem reported for history view in admin page. For history view there is a sql query generated, which trying to do exact look-up on OBJECT_ID column (LogEntry model, DJANGO_ADMIN_LOG table). "TextField" is responsible for handling large text and in DB2 "TextField" is mapped