On Wed, Nov 25, 2009 at 1:25 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Mon, Nov 23, 2009 at 11:00 PM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs <mario.bri...@in.ibm.com> >> wrote: >>> 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 something is >>> then the right choice. This is validated by what Karen says is the >>> Oracle fix. >> >> 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' > > The decision is based on the field type, not on the individual field. > If it were possible within the Oracle backend to override this > particular field to VARCHAR2, we would happily do it. But TextFields > in general need to be LOBs. > >> In theory, the contents of the object_id field could be anything - >> including a string of arbitrary length (i.e., a TextField). However, >> in practice, I would be surprised to see 4000+ characters for >> object_id - most primary keys are going to be integers, and the ones >> that aren't are likely to be short strings or string-like datatypes. > > Due to the hackish way the Oracle backend implements lookups on LOBs, > it will still fail if the object_id is actually longer than 4000 > characters. It might even raise an error (I haven't tried it). So at > least in Oracle we gain nothing by making this a TextField rather than > a CharField(max_length=4000). Plus, if it were a CharField, we would > be able to index it. > > Correct me if I'm wrong, but I think the only way to get an object_id > so large that it won't fit inside a backend-dependent CharField is if > the primary key of the model is itself a TextField. If you ask me, > anybody foolish enough to use a TextField as a primary key deserves > what they get. Oracle won't even allow it.
Your comment about foolishness is definitely correct :-) As for the CharField point - following this logic, we could define object_id as a CharField(max_length=N), for some large N. However, in the general case, we can't specify an N that is greater than all N's that end-users might use. Therefore, we use a TextField, which is unbound. 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. Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
