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 it was before, excepting 'smalltext' instead of 'longtext' for mysql? I think this is a point where "TextField is accessed by value" abstraction breaks, and better separation between long string and referenced object should be introduced. I assume we have not much Oracle & DB2 users yet, and nothing will change for them unless they already suffer from this problem and they will not anymore. Migration script is single "alter table" command, and that needs to be documented.
On Wed, Nov 25, 2009 at 6:09 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > 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. > > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
