change TEXT to Text

[Mike Bayer]

since the TEXT type generates CLOB and similar on some DB's, its not SQL-mapped, its generic. rename it to Text and deprecate TEXT in sqlalchemy.types.

[Former user]

I think that, in the assumption that uppercase are SQL-mapped and StudlyCased are generic, both Text and TEXT should be removed from sqlalchemy.types because types.String() with no length (=None) already generates TEXT columns, according to the docs (but I don't know if it also generates CLOB in some DBs). Text and TEXT should go to their respective backend modules (if it is necessary), or be removed completely.

[Mike Bayer]

The implementation currently works like this - you make a String with no arguments. When the dialect-specific implementation of String is searched for, the search path of classes is modified by String to include TEXT if it has no length; that way, instead of getting back MSString, OracleString, or PGString, each of which are mapped to the String type, you get back MSText, OracleText, of PGText, which are mapped to TEXT. So the dialects don't need to perform any kind of guesswork based on the length being present or not; each of their String types assumes a length is present and produces VARCHAR, each of their Text types assume length is not present and produce TEXT or CLOB in the case of oracle.

So there definitely needs to remain a base Text class at least for the sake of dialects.

What I would actually favor here is not the removal of Text, but removing the automatic conversion to TEXT from String. VARCHAR/CHAR and TEXT/CLOB are worlds apart from each other behaviorally, especially in oracle, and I think its a mistake that we take this difference to be casually associated with a length being present.

We could also go further to say that String's length should be required, however I think this is inconvenient for applications which are mapping to existing schemas and the length parameter is not used for anything.

Removing the auto string-to-text change would be a major backwards-incompatible change so we cant do it fully until 0.5. The full behavior would be, you can issue String(20), or String, but if you try to CREATE TABLE, the latter case would raise an error. Using String would produce VARCHAR/CHAR behavior and not TEXT/CLOB behavior (which are different on Oracle). For now I'd favor a deprecation warning if CREATE TABLE is issued from an un-lengthed String.

[Mike Bayer]

8fe38c7e956675eb9b6c859848200d8dcc7a9589

[Mike Bayer]

the implementation for this is utterly incorrect in every way. retry please.

[Mike Bayer]

eefd1f78a2ead8245791140e54fa3c32c4b41794

[Mike Bayer]

OK its good, but lets make the _for_ddl argument have the column name in it so the deprecation message can have the name of the col present.

[jek]

(and table.fullname)

[jek]

ok, the full column id is now in the warning. 3e9df22546cb4c7af0ece290f4f57a377516f142

[Mike Bayer]

Removing milestone: 0.4.xx (automated comment)